GONE PLAN 



A Rant 

on Ratings 



'The true danger is when liberty is nibbled 
away, for expedience, and by parts." 

— Edmund Burke 

Rating systems are crap. W ith the 
entire entertainment industry 
rolling over whenever Congress 
calls a hearing, it's fallen on us 
to denounce these initiatives for 
what they are— cynical postur- 
ing and electioneering with no 
substance. Rating systems, 
whether for movies, television, video 
games, or any other form of communica- 
tion, don't work, cost money, and impede 
creativity. Everyone at those hearings, 
politicians and witnesses alike, knows that. 
But there's nothing politicians love more 
than "standing up for the family" and 
blaming America's cultural violence on 
H ollywood. So the entertainment indus- 
try submissively pisses all over itself and 
proposes "voluntary" systems from the 
pathetic to the laughable. 

W hat are rating systems supposed to 
do? C urb the glorification of violence and 
sex. But "glorification" cannot be quanti- 
fied. W hich of the movies T rue L ies, N at- 
ural Born Killers, Schindler's List, and Wes 
Craven's New Nightmare glorifies violence 
and which denounces it? The rating sys- 
tem doesn't make a distinction— they're all 
rated R . 

I n the face of the failure of the 
M PAA rating system to control our 
national psyche, the ratings advocates 
don't make the logical conclusion that rat- 
ing systems are bogus, but instead say that 
the problem is that not enough things are 
rated! If our culture's general level of sex- 
ual frankness and violence has risen 
despite the movie rating system, it's only 
because other forms of entertainment have 
not yet been purified. 

Rating systems cost money. A ratings 
"board" (actually, a sizable and bureaucrat- 
ic institution) and its cost will be borne by 



the software companies. So much for the 
garage- based entrepreneurs trying to pull 
themselves up by their bootstraps with 
shareware games. 

Rating systems impede creativity. 
T hey do so in a perverse way, where bru- 
talities are traded off against each other. I 
can personally attest to the kinds of dis- 
cussions that happen all the time in H olly- 
wood: "Page 48, you've got the forcible 
injection of drugs. T hat's an X , rewrite it. 
Page 72— the rape scene. That's O.K." 
This dehumanization is fine, that dehu- 
manization isn't, let's do lunch. 

But the refrain is always, "W e need 
ratings systems to control what our chil- 
dren are exposed to." A parent in a video 
store once told me that her child might 
want to see R movies, but when she says 
no, the child knew not to argue. The 
corollary, I imagine, is that when she says 
notoaPG movie, the child argues. The 
favorite argument of "but all the other kids 
are watching it" is used by the child to 
subvert the very point of the rating system. 

And ultimately, the incident holds 
the right answer to controlling what chil- 
dren are exposed to. Parents should 
decide. If parents don't want their kids to 
play X-Com or see Terminator 2, they 
should say "N o" and put up with the ensu- 
ing argument. They don't need and 
shouldn't get a ratings system to supple- 
ment their authority. The government has 
no right to help parents say "No" at the 
video store if that governmental interfer- 
ence impedes your rights to develop what- 
ever content you feel appropriate. 

W e all have responsibilities. To cre- 
ate responsibly, to control the viewing and 
gaming habits of our own children, and to 
call the government's ratings initiatives 
what they are. Cynical, ineffective, 
oppressive, and wrong-headed. ■ 

Larry O'Brien 
Editor 
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by Our Readers 

We've only been 
around a little while. 

but we're already 
hearing from readers. 
In this, the first install- 
ment of our forum for 
your opinions, we've 
got a sampling of 
queries, criticism, and 
suggestions. 



Client/ 
Gaming 



Dear Editor: 

I was very excited when I saw your new 
magazine. Oddly, it's not because I 
ever hope to write a game per se. 
My job function is aptly described 
(using someone else's words) as a corpo- 
rate cubbyhole programmer. I've been 
using Toolbook and Multimedia Toolbook 
for a couple years. I know it isn't as 
manly as C++ or even Visual Basic, but I 
can pretty much do all the things, in 60 
scripting seconds, that take a Dr. Dobb's 
guy six nitty-gritty pages of text and code 
to describe. 

Using Toolbook, calling Q+E as my 
database access and Pinnacle's Graphics 
Server SDK, I can really get fast access to 
CSV datafiles and plot everything from 
bar charts to interactive (hot spot) bubble 
charts. I create transformed reports 
(transports) from my customers that give 
good GUI, good drill-down, and good 
graphical constructs of their data. 

Using Multimedia Toolbook, I cap- 
ture mainframe screens and add neat 
postage-stamp video to accomplish CBT. 
My fuzzy-grey cubbyhole for a better com- 
pression algorithm (or a horse)! 

So why am I telling this to Game 
Developer editors? Well, you've heard of 
infotainment and edutainment? Why not 
busutainment? Aside from its neat name? 

My son plays Math Blaster for Win- 
dows. It rewards him with a spaceship 
launch or trash to zap after accomplish- 
ing certain goals. Adults may be more 
amused if surprised by some Easter egg 
they stumble across. I have been known 
to make a user chase a normal looking 
button that jumps away randomly on 
mouseEnter. If you are very quick, you can 
nail it. 



Server 



Recently, a new game called Earth 
Invasion for Windows came out. It proves 
quite nicely that you can have arcade 
action in a "slow" graphical environment 
(I can spell that word because I was once 
a COBOL programmer). How much I would 
love to splice some of that action into my 
applications! Just to keep them eager to 
go on, of course. 

Your article about OLE 2.0 ("Let's Go 
Embed," Premier 1994) was right on, and 
I hope someday it will allow me all sorts 
of opportunities to use interesting game- 
creating authoring tools. Multimedia has 
caused everybody to buy faster PCs. Cer- 
tainly, they run Windows fast enough for 
something more than Solitaire now. Let's 
replace drag-and-drop with aim-and-fire. 
Twitch spreadsheets? Dbase thumb? 

The more I read about desktop virtu- 
al reality, the more I see myself running 
through my relational database like in 
Wolfenstein 3D, past orthogonal buildings 
(disguised as three-dimensional bar 
charts) of my data looking for the evil odd 
piece of data. Not as compelling as I 
would like, but maybe Comptons has 
already patented it. 

I get a small taste of this in Virtus 
VR, but they're more interested in show- 
ing off real buildings with real wire frame 
fireplaces and are not into anthropomor- 
phizing bad data (with TrueType labels) 
into gun-toting Nazis — yet. 

Edward Saur 
Flemington, N.J. 

Editor Larry O'Brien responds-. 
Heaven forbid that we talk about busi- 
ness software development in Game 
Developer. But since you did bring it up: 
humans have a set of evolutionary talents 
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that include competing, gathering, and 
hunting in a visually complex environ- 
ment. The computer game industry makes 
billions off the fact that these are so 
wired into the wetware that humans will 
pay for the privilege of exercising them. A 
business program that took advantage of 
these evolutionary strengths would proba- 
bly gain accolades for its "intuitive" and 
"friendly" interface. 



How Do You Get 
to Carnegie Hall? 

Dear, Editor: 

Could you give me some pointers as 
to what a college graduate should 
do as far as looking for work and 
what I should learn on my own to get into 
the game developing field? I realize most 
game developers write games in their 
spare time or start their own companies, 
but I thought you might have some sug- 
gestions for recent grads on what kind of 
work they should look for to help expand 
their knowledge in the field. Do game 
development companies hire recent grads, 
and if so what would they look for? 

Craig Tyler 
via the Internet 

Editor Larry O'Brien responds-. 
Your question is one that we get all the 
time, and we always give the same 
answer. There is no answer. Due to the 
relatively young age of the computer game 
industry, most of the game developers 
who are big names in the field started 
writing their own games themselves and 
companies grew up around them. Ask 10 
game developers how they got into the 
business, and you'll get 10 different 
answers. We plan to focus on this in the 
future, but there's no simple answer that 
we can give you here. 



Ratings Brouhaha 

Dear Editor: 

In response to Alex Dunne's editorial, 
"The Ratings Game" (Bit Blasts, Sept. 
1994), I am sure we will see some form 
of ratings system imposed on the industry 
sooner than later, and I can only hope that 
the system's creators somehow keep sim- 



plicity in mind (that is, they should not 
focus too heavily on it). 

I object to a simplistic level rating 
system (especially the one Dunne men- 
tioned that was proposed by someone on 
CompuServe) because it does not work. 
Using the groups presented, Lemmings 
would possibly qualify as a 5. While 
laughing about how absurd this sounds, 
press the mushroom cloud to detonate 
the Lemmings on the screen and bits and 
pieces of stuff fly out of the figures. Even 
Super Mario Brothers would rate at least 
a 2 — and possibly a 4, depending on 
which creature in which game you are 
considering. 

Rather than try to put all of the acts 
in a game into one linear category, I sug- 
gest that the game industry use some- 
thing similar to what I see now for many 
premium cable movie channels. The 
movies are rated with a simple letter code 
system that describes the content of the 
movies. AL means adult language, MV 
means mild violence, GV means graphic 
violence, AS means adult situations, N 
means nudity, BN means brief nudity, and 
so on. Of course no system is perfect, and 
certainly we need to work out what consti- 
tutes mild versus graphic violence. But 
the object of the rating system is to 
inform the potential buyer of the content 
of the product, not simply line up all of 
the games in an arbitrary linear scale. 

John Durbetaki 
Gaston, Ore. 



More Praise, Please! 

Dear Editor: 

Caught your second issue and I loved 
it! As an aspiring game developer 
and local musician I found the arti- 
cles deep and informative. It's good to 
know that some people know what guys 
like myself want in a magazine. I did 
notice some flaws in Jim Cooper's infor- 
mative article ("Computer vs. Console," 
June 1994), though. The Sega Genesis 
runs at about 7MHz and has 128K of 
memory not 12MHz with 512K of RAM. I 
thoroughly enjoyed Cooper's article. All 
and all, I think Game Developer gives a 
unique perspective on the gaming indus- 
try rarely seen in other magazines. 



Also, I was hoping Game Developer 
could get down and dirty on comparing 
the new consoles coming out and out 
already. For example, comparing the awe- 
some Doom on the Jaguar vs. the Sega 
32X version. I think readers would really 
like this. 

Ray Rivera 
Norfolk, Va. 



A Real Plan 

Dear Editor: 

The boom in interactive entertainment 
is clearly reflected in the glut of new 
computer entertainment periodicals, 
but most developer's magazines followed 
other trends. And so it seems that the 
debut of Game Developer this year was 
timely and auspicious. 

Although Game Developer is still 
thin, and has gotten pricey, each issue is 
more organized and carries the promise 
that later issues will be stronger. So far, 
the article topics have been appropriate, 
but unfortunately, much of the program- 
ming content lacks technical depth. Andre 
LaMothe's article, "The Mysterious Mode 
13h" (Sept. 1994), was especially 
appalling. LaMothe says, "Mode 13h is an 
obscure graphics mode that few game 
developers have mastered." Whoa! If you 
want to increase readership, don't pursue 
the newbies who probably won't subscribe 
anyway. 

Finally, I'm glad you gave standard 
names to your departments in the third 
issue, instead of article titles. The six 
departments do a lot to make Game 
Developer a "real" magazine. 

Tom Park 
via the Internet 



Game Over! 

We need your feedback! Send your cards, 
letters, and articlesuggestionsto: 

GameD ev eloper 
600 H arrison St., 4th Floor 
San Francisco, CA 94107 
Attn: Larry O'Brien 
E-mail iseven better: 
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Child's Play 



Diane Anderson 
and Nicole Claro 



PRODUCTS 




HUtOdeSh and Wa"t llisneu. Watch Out! 



Micr P*S 



two of four new 
animation options that 

promise to help 
you bring your 
graphics to life. Also. 

an update on the 
current game ratings 



trend. 




Having recently broken my finger, I 
am more than ever a slave to my 
computer. I can't write anything 
with a normal implement, so I 
have to skip the "pen- and- paper" step 
and jump right to the keyboard. Not 
only that, but I 'm obsessed with the fact 
that if I put my hair into a ponytail, it 
will always flop to the left (it's messing 
up my karma, I think). h how I wish I 
had a cool, new animation program to 
take me away.... 

Autodesk's award- winning, widely 
used two-dimensional animation soft- 
ware, A nimator Pro, has been around for 
a few years now. Recently, the company 
announced the upcoming launch of Ani- 
mator Studio Release 1, a W indows 3.1- 
based successor to the Animator Pro 
tools. T he company calls A nimator Stu- 
dio a "powerful. ..2D animation produc- 
tion package with direct application to 
2D film, TV, and video production." 

With its new product, Autodesk 
seeks to break the boundaries between 
multimedia development venues and tra- 
ditional graphic art studios. Animator 
Studio merges the two, allowing the user 
to create animation with "onion skin- 
ning," much like working on a light 



table; integrating 24-bit Truecolor paint 
and plug-in interfaces for Photoshop fil- 
ters to be used as ink, which make the 
transition from still-image editing to 
animation even smoother; and providing 
a digital sound studio designed specifi- 
cally for animation. The sound module 
lets you manipulate soundtracks in any 
way you need to, squeezing or stretching 
music to make it fit, recording from CDs 
and tapes and then layering the sounds, 
or adding special effects such as reverb or 
pitch shifting to music or vocals. W hile 
recording your sound or narration, you 
can view your animation in a separate 
video window simultaneously. 

Autodesk Animator Studio reads 
and writes in many formats, including 
AVI, FLI and FLS, BM P, TGA, 
TIFF, JPEG, GIF, and PCX. Suggest- 
ed list price is $795. 

For More Information Contact: 
Autodesk Inc. 
2320 Marinship Way 
Sausalito, Calif. 94965 
Tel: (415) 332-2344 

Narriage Announcement 

3D Labs and Argonaut Software are 
joining forces. 

3D L abs' GLINT two-dimensional 
processor is capable of 300K shaded, 
depth bufffered, anti-aliased polygons 
per second. It offers Gourard shading 
and texture mapping, 32-bit color, two- 
and three-dimensional acceleration, and 
an on-chip Peripheral Component 
Interconnect (PCI) local bus interface. 
According to 3D Labs, the G LINT 
processor is "ideal" for penG L or 
other 3D APIs. 
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A rgonaut Software's B Render three- 
dimensional API provides scalable perfor- 
mance, true z- buffering, and perspective 
texture mapping across a wide range of 
computer and games platforms B Render 
is intuitive and compact. 

CombineGLINT and BRenderand 
you've got high-performance rendering 
power. The partnership of the two com- 
panies promises to be a formidable force 
in the W indows and W indowsN T graph- 
ics market. 

For More Information Contact: 
3DLabs Inc. 

2010 N. First St., Ste. 403 
San J ose, Calif. 95131 
Tel: (408) 436-3455 

Winng the Toon 

WinToon is M icrosoft's latest product 
announcement. Addressing the strong 



demand for animated titles, M icrosoft's 
new animation playback tool for Win- 
dows facilitates the creation of full- 
screen multimedia titles. 

Its toolset includes the W inToon 
run-time engine. W inT oon uses the 
Video for W indows architecture to 
allow developers blue- screen capabilities 
for superimposing images (remember 
Jurassic Park?). W inToon's scan-time 
engine digitizes traditionally animated 
characters, and its playback engine helps 
with design review. M icrosoft promises 
the user "richer, more fluid, and more 
realistic animation" with W inToon. 

Because the new W indows operat- 
ing system will have a W inG API and a 
display control interface (DCI) built 
in— along with 32-bit implementation 
of the V ideo for W indows architec- 
ture—multimedia soon may have set 
standards. 



For More Information Contact: 
Microsoft Inc. 
1 Microsoft Way 
Redmond, Wash. 98052-6399 
Tel: (800) 426-9400 



One Board. One World 




M atrox G raphics I nc. is now shipping 
theMGA I mpression Plus, a one- board, 
three-dimensional graphics accelerator 
that provides fast W indows, three- 
dimensional, and video on the PC. The 
MGA I mpression Plus features a flexible 
architecture that provides complex dri- 
vers to optimize W indows, multimedia, 
CAD, and three-dimensional applica- 
tions. The 64-bit acclerator uses 
M icrosoft's DCI API for smooth video 
playback at resolutions up to 1,280- by- 
1,024 at 30 frames per second. It's also 
the only graphics accelerator that lets 
you upgrade to the VESA Media Chan- 
nel (VM -Channel). The VM -Channel's 
open specification accepts up to 15 video 
streams, so you can add on any VM - 
based multimedia peripheral. 

TheMGA I mpression Plus is ship- 
ping for $449 and includes the M GA 
three-dimensional-SuperPack, a three- 
dimensional CD-Rom with three 
games— Sento, Spectre MGA, and Ice 
H awk— three-dimensional viewing files, 
and three-dimensional library demos. 

For More Information Contact: 
Matrox Graphics Inc. 
1055 Saint-Regis 
Dorval, Canada H9P 2T4 
Tel: (514) 685-2630 



D iane Anderson is editorial assistant 
for G ame D eveloper magazine. Nicole 
Claro is production editor for G ame 
Developer magazine. 



Industry News: More to Hate About Ratings 



First we had to deal with our parents forbidding us from seeing R-rated movies, then 
came that music label Identification scandal, now this. Now our games and the very 
digital frontier we hold sacred are being threatened. Cyberla Is Inherently anarchic, 
chaotic, and methodic In Its madness. Down with censorship! See Alex Dunne's com- 
ments ("The Ratings Game," Bit Blasts, Sept. 1994) and Larry O'Brien's comments In 
this month's Game Plan. 

The Recreational Software Advisory Council (RSAC), a group established to "Implement and 
oversee a national ratings system," recently elected Robert Roden as Its president. "So 
what!" you scorn. "Who's he?" you ask. Well, as It turns out Robert Roden Is not only the 
president of RSAC, he's also a member of the LucasClub. He's the "general counsel and direc- 
tor of business affairs" for LucasArts Entertainment. 



Coincidence? Conflict of Interests? Ironically, RSAC's nine-member board Is 
designed to "ensure the ratings system will be Independent of the soft- 
ware Industry's control." With a software bigwig as Its president? Seems j 
unlikely. j 




The RSAC rating system assigns to a product a numerical score between zercj^^** 
and four across three categories- violence, sex/nudity, and language. Any scores above zero 
are posted on the product's packaging. Developer participation is voluntary, but retailers are 
wary of carrying nonrated products. 

"RSAC's system has nothing to do with censorship or with telling developers what to put in 
their games," Roden says. (But developers who get an unfavorable rating will obviously be 
stigmatized; such labeling may damage or boost sales.) Roden innocently claims the organi- 
zation's "purpose is to inform consumers what's in the box." If parents are so concerned with 
what's in boxes they're buying for their kids, parents should consider checking out the games 
themselves instead of depending on an outside agency to babysit the floppy babysitter. What 
ever happened to quality time? 

And why haven't Tom Sawyer and Catcher in the Rye been banned from all high school read- 
ing lists yet? 
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Revenge of 
the Sequel 
Syndrome 



by Alex Dunne 

Like many current 
movies, popular 
gomes ore spawning 
on explosion of 
sequels, look-olikes, 
and ujonnabes. (Ilex 
Dunne looks at Ike 
trend and makes his 
case for originolitu. in 
concept and design. 



What do Friday the 13th, 
R ocky, and N ightmare on 
E Im Street have in common? 
If you answered, T hey're all 
movies that spawned a 
never-ending series of 
sequels," you got it. It's a 
formula that works for the 
studios: After the first movie is deemed a 
success, Movie 2 or Revenge of the Bad 
Guy From The Last M ovie invariably 
comes out the following year. At the 
same time, the rest of the movie industry 
latches onto the "look and feel" of the 
movie and releases look-alikes. 

You've probably seen enough of 
these movies to know the formula. Per- 
haps you enjoyed a few of them, too. B ut 
how many of these sequels and look- 
alikes would you describe as unforget- 
table? If I saw a movie and came out of it 
thinking, T hat was Raiders of the Lost 
Ark starring Michael Douglas," I 
wouldn't recommend it to anyone. 
U nfortunately, I 'm feeling this way about 
a growing number of games. 

I fear that this mentality is becom- 
ing prevalent within the game industry as 
well. H ow many different football and 
baseball games are on the market today? 
H ow many air-combat simulators? If I 
had to sum it up, I'd say, "a lot." Are 
there too many? At the rate that sequels 
and look-alikes are hitting the market, I 'd 
hazard to say that most of them are 
financially successful enough to justify 
their development. But as a developer, 
you've got to ask yourself, "Should I ride 
the coattails of the latest game craze or 
create a completely new type of game and 
risk an unresponsive market?" In 
response to thisdilemma, let's look at: 



• Some reasons for developing a sequel 
or look-alike game 

• W hat W indows '95 offers that will 
spur developers' imaginations 

• A relationship between a hardware 
vendor and game developer that 
spawned a stunning new game. 

O.K., There are 
Compelling Reasons 

D on't get me wrong, there are sound rea- 
sons for developing look-alikes and 
sequels. Look-alikes tap into hot market 
crazes and can turn a great profit for their 
developers. The reception that Doom 
received has companies like Capstone 
negotiating with Id Software to use its 
technology. Asa result, Capstone's Cor- 
ridor 7 looks strikingly similar to 
Doom— but I'll venture that it does fairly 
well in the market. 

Sequels tap into name recognition 
and their predecessor's story lines and are 
especially prevalent in adventure and role- 
playing games. The market knows the 
products already, so most of the market- 
ing department's job is done. T he look 
and feel of the game is established, so cre- 
ative folks don't have to sweat out many 
conceptual changes Perhaps much of the 
interface code can be reused, saving the 
developers' time. W ith reasons like this, 
who'd knock the idea of a sequel? 

I f it's done right, probably nobody. I 
am simply championing the idea that you 
might be rewarded an order of magni- 
tude more by going out on a limb with a 
fresh game idea than by choosing a less 
risky game concept. Develop a truly 
groundbreaking game and suddenly 
you're all alone, and your competitors are 
scrambling to catch up. Although it's 
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been talked up to death, M yst is the per- 
fect example. I find that when I try to 
describe M yst to someone, I can't use 
another game as a reference. M yst, by 
virtue of being so different, has been a 
financial boon for both the Rand brothers 
and Broderbund. 

Microsoft's New 
Game Platform 

Among the most talked about events in 
the industry and one that has significant 
potential to change the face of gaming is 
W indows '95. N ow that M icrosoft has 
gone through two beta cycles of the oper- 
ating system, developers are getting a feel 
for its abilities. T he capabilities W indows 
'95 offers over DOS should lead to some 
incredible new games. 

W indows '95 promises to be a com- 
petitive platform to DOS when it comes 
to game speed and adds some benefits not 
found in the old 16-bit operating system. 
Coupled with OLE, M icrosoft envisions 
the ability to drag and drop game ele- 
ments, the use of standard game interfaces 
that developers could use to extend a 
game's functionality, and the possibility of 
embedding game sessions into mail mes- 
sages that would automatically connect 
you to another player over a network or 
modem. 

The ability to develop network mul- 
tiplayer games will be greatly enhanced 
with W indows '95. D evelopers won't 
have to write the networking code or 
work around the network's memory 
space. Using W inSockets, game develop- 
ers will be able to write games for a wide 
range of networks including Novell, 
TCP/IP, W indows for W orkgroups, 
Banyan Vines, and LAN Manager. 

In what looks to be a boon for the 
phone companies, W indows '95 will pro- 
vide support for a new modem technology 
called VoiceView, which will ship as a 
standard feature of many modems begin- 
ning in 1995. VoiceView will let modem 
users talk on the phone and use their 
modem over the same line. The technol- 
ogy is suited to games where each player 
takes a turn, such as chess, allowing the 
computer to take over the phone line to 
transmit game data and then relinquish it 
back to the callers for further conversa- 



tion. Simple messages (such as a chess 
move) would take less than a second. 

This will make modem- based games 
much more popular because players will 
be able to enjoy the benefits of coordinat- 
ing team play (or cursing at each other) as 
they play. T his of course will be a tremen- 
dous boon to game distributors who bun- 
dle phone cradles and chiropractic 
coupons with their games. 

Perhaps the most significant aspect 
of the new W indows '95 system is the 
much touted WinG graphic library. I 
don't have to convince anyone how pitiful 
game performance is under W indows 3.1. 
M icrosoft claims that its come close to 
matching DOS game speeds using the 
WinG library under W indows '95. 

It's unclear when W indows '95 is 
going to be released. As of late October, I 
can only say (as M icrosoft is) that it will 
be available sometime between April and 
June 1995. The acceptance rate of W in- 
dows '95 into homes is hard to project, 
however, so it's difficult to determine how 
large the market for W indows '95 games 
will be. Given Solitaire's popularity when 
W indows 3.0 came out, M icrosoft is 
probably praying for some killer W in- 
dows '95 games to speed the system's 
adoption into family rooms. T hese "killer" 
games, I predict, will be innovative and 
make the most of Windows '95's 
enhancements. 

Hardware Advancements 
Spur Innovation 

A nother angle developers are beginning to 
pursue in their quest for breakthrough 
games relates to hardware advancements. 
Back when sound cards first entered the 
market, card vendors courted developers 
to write games that supported their hard- 
ware. Asa result of Creative Labs' dili- 
gence and marketing savvy, every major 
game today supports the Sound Blaster, 
and it has become the de facto standard. 

Now, a video card manufacturer, 
M atrox, has come along with the power- 
ful new MGA Impression Plus accelera- 
tor card that incorporates a three-dimen- 
sional polygon engine. M atrox is hoping 
to popularize the accelerator among game 
players and, to further this aim, has estab- 
lished a partnership with start-up game 



developer 47-Tek. 47-Tek is creating a 
battle game titled Sento that is optimized 
for the card and features very cool real- 
time animation. Sento's use of the card's 
engine creates a unique visual experience 
that makes other fighting games pale in 
comparison. 

U nfortunately, Sento's performance 
under other video cards doesn't match the 
optimized conditions that the M atrox 
accelerator provides. It's possible to fore- 
see a game so narrowly optimized for a 
particular computer configuration that a 
nonoptimal setup would bring the game 
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Other combat games pale in comparison 
to Sento, which uses the Matrox acceler- 
ator to its maximum potential. 



to its knees. That, of course, would seri- 
ously affect the size of the game's market. 
47-Tek has sidestepped this problem by 
bundling Sento with the hot-selling 
M atrox card, but of course that's not an 
option for every developer. 

Perhaps the M atrox card will 
become a de facto standard for three- 
dimensional polygon-based games— 
though I doubt it (the world can only 
handle so many standards). n the other 
hand, the symbiotic relationship between 
M atrox and 47-Tek might become a 
standard, one best suited for start-up 
developers looking for a niche. 

So, as you begin brainstorming your 
next game, keep in mind the sequel syn- 
drome. Experiment with new concepts 
and ideas, rather than rehashing old ones. 
Look around at new technologies the 
industry is offering, and capitalize on 
them. It comes down to this: D o you 
want your game to be the next ground- 
breaking hit or the next Romandng the 
Stone?Takethe road less travelled. ■ 

Alex D unne is contributing editor for 
G ame D eveloper magazine 
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Mode X 
Revealed 



by Matt Pritchard 

Frustrated bi| the 
limitations of Mode 
13H? Try Mode X. the 
graphics mode that 

promises better 
screen resolutions, 
page flipping. 

hardware screen 
scrolling, and super 
rich color. 



Graphics are one of the most 
important parts of any game 
today, yet the VGA standard 
comes up short in providing 
the features and power many 
games demand. "M ore col- 
ors!" That's what the VGA 
promised over its predeces- 
sors. "Pick any 256 from a quarter mil- 
lion!" it said. Unfortunately, as 
designed by I BM , only one mode actu- 
ally delivered this promise of rich color: 
M odel3h. 

But there was a catch. M ode 13h 
did not provide many features game 
designers wanted— features they were 
accustomed to on other platforms. 
Screen resolution was limited. Hard- 
ware scrolling was out. Page flipping 
was a pipe dream. If you wrote a game 
using mode 13h, screen flicker was a 
constant enemy that limited your 
graphics and animation. Super VGA 
cards came out and provided more 256- 
color mode options, and some even 
provided page flipping. But there were 
no standards between brands and 
makes of VGA cards. D evelopers need- 
ed something that would work on any 
VGA card, from the first IBM VGA 
built into a PS/2 to the latest 4M B 
super duper VGA card. That some- 
thing turned out to be M odeX. 

Back in 1989, someone got down 
with the IBM VGA internals, took a 
close look at the internal registers and 
workings of M ode 13h, and discovered 
that nothing was etched in stone. This 
unsung hero determined that features 
from the EGA 16-color modes could 
be blended into M ode 13h to create a 
hybrid video mode with more accessi- 



ble video memory and more usable 
hardware features. From that discovery 
we have what is commonly referred to 
as M ode X . M ode X gives us access to 
the following features that are lacking 
in M odel3h: 

• H igher screen resolutions 

• H ardware screen scrolling 

• Page flipping (the key for smooth 
animation). 

The Technical Details 

Game programmers everywhere have 
heard of M ode X, but for many it is 
still mysterious or unclear. The biggest 
reason for confusion is that M ode X is 
not a hard-and-fast video mode, but a 
label for any number of derived modes 
that have one thing in common: 
Unchained Video M emory Access. Let 
me explain. 

A big limitation of VGA graphic 
modes is that there is only a 64K win- 
dow of address space at segment aooo 
through which to access graphics mem- 
ory. EGA 16-color modes allow access 
to up to 256K of video memory by 
mapping four "video planes" over each 
other in the same 64K of address space. 
So, 4 bytes of video memory are actual- 
ly mapped into each single byte of 
address space. Special control registers 
let the programmer set the four video 
planes which are actually mapped in at 
any given time. In M ode 13h, none of 
this exists. There is only one byte of 
video memory for each memory 
address, limiting this mode to 65,536 
pixels maximum. W ith a screen resolu- 
tion of 320- by-200, 64,000 of those 
pixels are used. Tragically, 192K of a 
standard VGA card's 256K of video 
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Listing 1. Modex.C (Continued on p. 27) 



#indude <stdio.h> 
#include "setmodex.h" 

void shou_X_Mode(int Mode_Num, int X_Res, int Y_Res, int Scroll. Flag) ; 
void modex.rect (int UL_X, int UL_Y, int LR_X, int LR_Y, int Color); 
void modex.hline (int Left_X, int Right.X, int Y, int Color); 
void modex.vline (int Top_Y, int Bottom.Y, int X, int Color); 

void main (void) 
{ 

show_X_Hode(Mode_320x200, 320, 200, 0); 

show_X_Hode(Mode_320x240, 320, 240, 0); 

show_X_Hode(Mode_320x400, 320, 400, 0); 

show_X_Hode(Mode_320x480, 320, 480, 0); 

show_X_Hode(Mode_360x200, 360, 200, 0); 

show_X_Hode(Mode_360x240, 360, 240, 0); 

show_X_Hode(Mode_360x400, 360, 400, 0); 

show_X_Hode(Mode_360x480, 360, 480, 0); 

show_X_Hode(Mode_320x200, 512, 500, 1); 

set_text_mode(); 

printf ("This Demo is finished\n") ; 

} 

void shou_X_Mode(int Mode_Num, int X_Res, int Y_Res, int Scroll. Flag) 
{ 

int x, y; 

set_text_mode(); 

if (Scroll.Flag == 0) { 

printf ("\n\nPress any key to see Mode X at '/,d by '/,d resolution\n\n", 
X.Res, Y_Res); 

} else { 

printf ("\n\nPress any key to see a Mode X Scrolling windou\n\n"); 

} 

printf ("(When done, press any key to end the mode X display)"); 
y = scan_keyboard(); 

set_vga_modex(Mode_Num, X_Res, Y_Res); 

for (x = 0; x < 15; x++) { 

modex_rect(x*3, x*3, X_Res-x*3-l, Y_Res-x*3-l, x+1); 
modex_hline(32+x*4, X_Res-96+x*4, 20+x*10, x+1); 
modex_vline(32+x*4, Y_Res-96+x*4, 20+x*10, x+1); 

} 

if (Scroll.Flag) { 

for (x = 0, y = 0; x < 100; x++, y++) set_uindou(x, y); 
for (y = 100; y >= 0; y— ) set_uindou(100, y); 

for (x = 100; x >= 0; x— ) set_uindou(x, 0); 

} 

y = scan_keyboard(); 
return; 

} 



memory goes to waste here, in the only 
256- color mode. The "secret" of M ode 
X is that it lets the programmer use the 
full 256K of VGA memory instead of a 
mere64K by borrowing the EG A's mul- 
tiple video plane system. This is accom- 
plished by turning off a control register 
known as Chain-4 (unchaining) in the 
VGA card. nee this is done, 4 bytes of 
video memory are found at every memo- 
ry location in the A000 segment. 

W ith a quarter million pixels avail- 
able to work with, the first thing people 
experimented with was changing the 
screen's displayed resolution. M odel3h 
has no memory to spare for a larger 
screen, but M ode X has enough memo- 
ry for a screen resolution of 512-by-512 
pixels. H owever, just because there is 
enough memory doesn't mean the VGA 
card can display it. Reprogramming the 
registers that control the screen resolu- 
tion is tricky. It is possible to play 
around with the VGA's CRT controller 
registers and come up with all sorts of 
strange resolutions. H owever, we want 
to stick with known settings that will 
work on any monitor and VGA card. 
Two horizontal resolutions and four 
vertical resolutions that follow estab- 
lished VGA modes fit our needs. These 
can be combined to create eight differ- 
ent screen resolutions for M ode X . 

T he standard M ode 13h resolution 
is 320- by-200 pixels and makes a good 
default for M ode X. This is the M ode 
X resolution used by games such as 
Doom and Ultima Underworld. The 
horizontal resolution can be safely 
increased to 360 pixels by setting the 
VGA card to use the 28M H z dot clock 
(used in text modes) instead of the 
25M Hz dot clock used in graphics 
modes. Some individuals claim that the 
higher frequencies damage their moni- 
tors. This is not true, and there has 
never been a known case of monitor 
damage because of it. Regrettably, 
higher horizontal resolutions such as 
640 pixels are not available in a stan- 
dard VGA because of video memory 
clock speed limitations. 

Vertical resolution provides even 
more choices; 200-line modes are actu- 
ally 400-line modes in disguise. These 
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modes use the MSL register in the VGA's 
CRT controller to draw each scan line 
twice. Set that register to 0, and you 
have 400 lines of vertical resolution. By 
borrowing the vertical display settings 
from M ode 12h (640-by-480, 16- color 
graphics), we get 480 lines of glorious 
256-color graphics, although the screen 
refresh rate slows from 70H z to 60H z. 
Finally, in this mode, setting the MSL 
register back to 1 gives you 240 pixels 
vertically. 

H orizontal and vertical screen reso- 
lutions can be combined as desired, but 
one combination is worthy of special 
notice: 320-by-240 pixels. On a VGA 
monitor, this resolution has an aspect 
ratio of 1:1, which gives it perfectly 
square pixels and easily allows for true 
squares and circles on the screen. 

Once you set a screen resolution, 
you can set a "virtual resolution." This 
lets you create a "virtual screen" larger 
than the displayed resolution. The 
screen display then becomes a window 
into the larger virtual screen, and the 
"window" can be moved and scrolled 
around. In M ode X, this is accom- 
plished by setting the VGA card's Offset 
Register with the width of the desired 
virtual screen divided by 8. This creates 
the virtual screen, which can be wider 
than the 320 or 360 displayed pixels. 
The Start Address registers the position 
of the upper left corner of the screen 
display in video memory in the VGA's 
CRT controller control. Because each 
address has 4 bytes (4 pixels at 1 byte 
per pixel) mapped into it, when you 
change the start Address register by 1, 
the screen display will shift by 4 pixels. 
To move a single pixel at a time, use the 

Horizontal Pixel Planning register in the 
VGA's Attribute controller. It can only 
shift the display up to 3 pixels in M ode 
X, but when you use it in conjunction 
with the Start Address registers, 
smooth, full-screen scrolling is possible. 

Setting Mode X 

So far, I have avoided getting very spe- 
cific about the VG A registers and 
processes. At the end of this article, I 
have included an assembly language 
listing, M odex.asm (Listing 3), which 



Listing 1. Modex.C (Continued from p. 26) 



/* ===== Simple Mode-X Line draw routines ===== */ 

void modex.rect (int UL_X, int UL_Y, int LR_X, int LR_Y, int Color) 
{ 

modex_hline(ULJ, LR.X, UL_Y, Color); 

modex_hline(UL_X, LR.X, LR_Y, Color); 

modex_vline(UL_Y, LR.Y, UL_X, Color); 

modex_vline(UL_Y, LR.Y, LRJ, Color); 
return; 

} 

void modex.hline (int Left_X, int Right.X, int Y, int Color) 
{ 

int x; 

for (x = Left_X; x <= Right.X; x++) set_point(x, Y, Color); 
return; 



void modex.vline (int Top_Y, int Bottom.Y, int X, int Color) 
{ 

int y; 

for (y = Top_Y; y <= Bottom.Y; y++) set_point(X, y, Color); 
return; 
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Listing 2. Modex.H 



#ifndef SETHODEX_H 

#define SETHODEX_H 

/* ===== SCREEN RESOLUTIONS ===== */ 

#define Mode_320x200 

#define Mode_320x400 1 

#define Mode_360x200 2 

#define Mode_360x400 3 

#define Mode_320x240 4 

#define Mode_320x480 5 

#define Mode_360x240 6 

#define Mode_360x480 7 

/* ===== mode X SETUP ROUTINES ===== */ 

int far pascal set_vga_modex (int Mode, int MaxXpos, int MaxYpos); 
void far pascal set_text_mode (void); 
int far pascal scan.keyboard (void); 

/* ===== BASIC GRAPHICS PRIMITIVES ===== */ 

void far pascal set.point (int Xpos, int Ypos, int Color); 
int far pascal read.point (int Xpos, int Ypos); 
void far pascal set.uindou (int XOffset, int YOffset); 

#endif 



contains a routine that will set up M ode 
X at any of the eight resolutions that I 
described and create any sized virtual 
screen to order. Additional routines, 
which we will discuss, show how to plot 
pixels, read pixels, and scroll a virtual 
screen. I have also included two short 
demo programs, M odex.C and 
M odex.H , shown in L istings 1 and 2 
and written in Borland C++ 3.1. They 
show each M ode X screen resolution 
and virtual screen scrolling. Both list- 
ings use the medium memory model. 



Switching the computer's display 
into M ode X involves a few basic steps. 
First, you call theVGA's BIOS to set the 
display to M ode 13h. Some people have 
bypassed this step and do it manually, 
but I advise against it. M any super 
VGA cards have extra registers and fea- 
tures that are not part of the VGA stan- 
dard. Calling the BIOS allows the VGA 
card to set any special or unique fea- 
tures it might have and ensures maxi- 
mum compatibility. After M ode 13h is 
set, you disable the Chain-4 register in 



the VGA sequencer. N ext, you will 
need to invoke an asynchronous reset 
on theVGA card. W hiletheVGA isin 
a reset state, you can change the hori- 
zontal dot clock. After ending the reset, 
you then load the CRT Controller's regis- 
ters with the values for the desired hori- 
zontal and vertical resolutions. Some 
registers are protected from accidental 
modification so a protection register 
must be turned off before starting and 
turned back on when finished. Finally, 
the virtual screen width must be set. At 
this point, the desired version of M ode 
X is set up and ready to go. Usually, the 
next step isto clear all theVGA's video 
memory completely, so any leftover 
garbage will not appear on the screen. 
To do this, you need to know how to 
write pixels in M odeX. 

Drawing Mode X Pixels 

I n M ode 13h, drawing pixels is very 
simple. You just write the desired byte 
value to address (320 * Y) + X. I n M ode 
X, it gets a lot more complicated 
because there are four pixels at each 
memory address. This is where the Map 
Mask register comes in. As part of the 
VGA's sequencer, it acts like a control 
valve for each of the four video planes, 
determining if a byte written by the 
CPU will be passed through to each of 
the four video planes or ignored com- 
pletely. W hile it is a hassle to set the 
Map Mask register for each pixel to plot, 
doing so can be beneficial if we want to 
write the same color value to more than 
one video plane at a time. If all video 
plane access bits in the Map Mask register 
are set to 1, a single byte written by the 
CPU will be simultaneously copied to 
all four video planes, setting four pixels 
with a single byte. Alas, this is a topic 
unto itself that we must save for later. 

So, how do you determine the 
address of a given pixel that you want to 
write to location (X,Y)? The formula is 
similar to mode 13h but requires two 
more steps. First, you multiply the Y 
position by the virtual screen width (or 
display screen width if they are the 
same) and add the x position— just like 
M ode 13h, except that the width does 
not have to be 320. Then you take the 



Mode I is nor o hard-and-fasr video mode, 
bur a label for derived modes Thar have 
Unchained Video Memory Access. 
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result and divide it by 4. T he whole 
number that results is the address in the 
aooo segment that you need to write to, 
and the remainder is the video plane 
number from to 3, as shown here: 

Rau.Address = (Y_pos * Screen_Width) 
+ X_pos 

Memoryjddress = Raujddress / 4 
Plane.Number = Raujddress MOD 4 

"MOD" is the modulus/remainder function. 
In C/C++ this is the "'/," operator. 

Because the numbers involved can 
exceed 65,536, most people first divide 
the video width and X position by 4 to 
avoid an overflow and get the plane 
number from the X position, as shown 
in this equation: 

Memoryjddress = (Y_pos * Screen.Width 

/ 4) + X_Pos / 4 
Planejumber = X_pos HOD 4 

In either case, you wind up with a 
memory address and plane number. 
The four pixels at a given memory 
address will appear next to each other, 
left to right starting with plane #0. The 
very first pixel is at address 0, plane #0, 
followed by address 0, planes #1, #2, and 
#3. Then comes address 1, plane #0, and 
so on. 

Before you can write the color 
value to the memory address, the Map 
Mask register must have the bit corre- 
sponding to the desired plane number 
set. You do this by loading the value Olh 
for plane #0, loading 02h for plane #1, 
loading 04h for plane #2, or loading 08h 
for plane #3 into the AH register, loading 
02h into the al register (to select the Map 
Mask register), and ouring the ax register 
to port address 03C4h. Once that is 
done, any data you write to A000:Memo- 
ryjddress will only go to the desired 
video plane. Examine the set.point rou- 
tine in Listing 3 for an example of 
M odeX pixel plotting. 

Reading Mode X Pixels 

Reading a pixel in M ode X is similar to 
writing one, except you can access only 
one video plane at a time. You still need 



Listing 3. Modex.asm (Continued on p. 30) 


.MODEL Medium 




.286 




; Macros to OUT 8 & 16 bit values to an 1/0 port 


0UT.16 MACRO Register, Value 




IFDIFI <Register>, <DX> 


; If DX not setup 


MOV DX, Register 


; then Select Register 


ENDIF 




IFDIFI <Value>, <AX> 


; If AX not setup 


MOV AX, Value 


; then Get Data Value 


ENDIF 




OUT DX, AX 


; Set I/O Register(s) 


ENDM 




0UT.8 MACRO Register, Value 




IFDIFI <Register>, <DX> 


; If DX not setup 


MOV DX, Register 


; then Select Register 


ENDIF 




IFDIFI <Value>, <AL> 


; If AL not Setup 


MOV AL, Value 


; then Get Data Value 


ENDIF 




OUT DX, AL 


; Set I/O Register 


ENDM 




; macros to PUSH and POP multiple registers 


PUSHx MACRO Rl, R2, R3, R4 




IFNB <R1> 




PUSH Rl 


; Save Register 


PUSHx R2, R3, R4 




ENDIF 




ENDM 




POPx MACRO Rl, R2, R3, R4 




IFNB <R1> 




POP Rl 


; Restore Register 


POPx R2, R3, R4 




ENDIF 




ENDM 




; VGA Register Addresses 


ATTRIB.Ctrl EQU 03C0h 


VGA Attribute Controller 


GC.Index EQU 03CEh 


VGA Graphics Controller 


SC_Index EQU 03C4h 


VGA Sequencer Controller 


CRTC.Index EQU 03D4h 


VGA CRT Controller 


MISC.OUTPUT EQU 03C2h 


VGA Misc Register 


INPUT.l EQU 03DAh 


Input Status #1 Register 




; VGA Register Index Values 


PIXEL.PAN.REG EQU 033h 


Atrb Index: Pixel Pan Reg 


MAP.MASK EQU 002h 


Sequ Index: Map Mask Reg 


READ.MAP EQU 004h 


GC Index: Read Map Reg 


START.DISP.HI EQU OOCh 


CRTC Index: Disp Start Hi 


START.DISP.LO EQU OODh 


CRTC Index: Disp Start Lo 


; other VGA Register Values & Constants -==-= 


ALL.PLANES.ON EQU OOF02h 


Map Register + AH Planes 


CHAIN4.0FF EQU 00604h 


Chain 4 mode Off 
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to calculate the memory address and 
plane number, but you will set the Read 
Map register in the VGA's Graphics con- 
troller instead of the Map Mask register. 
Unlike the Map Mask register, this regis- 
ter just needs the plane number from 
to 3. 

Specifically, you need to load ah 
with the plane number, AL with 04h (to 
select the Read Map register), and OUT AX 
to 03CEh. After that, you read the byte 

at A000:Memory.Address and it will return 

the value of the desired pixel. Examine 
the READ.POINT routine in Listing 3 for 
an example of M odeX pixel reading. 

Scrolling the Screen 

Once you know how to address pixels 
in M ode X, it is easy to scroll a window 
around a larger virtual screen. All you 
need to know is which pixel should 
appear in the upper left corner of the 
screen. With that, you compute the 
address and plane number of the pixel. 
The 16-bit address is loaded into the 
CRT controller's Start Address registers. 
You then multiply the plane number by 
2 and load it into the Horizontal Pixel 
Panning register of the VGA'S Attribute 

controller. Occasionally, this process 
may produce shearing of the display 
screen. To avoid this, the Horizontal 
Pixel Panning register is usually updated 
during the display's vertical blank peri- 
od. Examine the SET. WINDOW routine in 
Listing 3 for an example of virtual 
screen scrolling. 

W hew! This M ode X stuff is cer- 
tainly more involved than M ode 13h, 
but the results are worth it. W e have 
only scratched the surface of M ode X, 
and in future articles I hope to cover 
ways to use M ode X's unique features 
to produce fast and efficient graphics 
routines such as page flipping, block 
fills, and sprites. U ntil next time, happy 
coding! ■ 



M att Pritchard is a software devel- 
oper for Lacerte Software in D allasT exas, 
and the author of M ODEX 110 a compre- 
hensive freeware M ode X library. He can 
be reached at matthewp@netcom.com or 
through G ame D eveloper. 



Listing 3. Modex.asm (Continued on p. 31) 



ASYNC.RESET 
SEQU.RESTART 
VGA.Segment 
VERT.RETRACE 
PLANE.BITS 
nil 
uptr 
dptr 
.DATA? ;= 
CURRENT.PAGE 
CURRENT.SEGMENT DW 
SCREEN.WIDTH DW 
MAX.XOFFSET DW 
MAX.YOFFSET DW 



EQU OOlOOh 
EQU 00300h 
EQU OAOOOh 
EQU 08h 
EQU 03h 
EQU OOh 
EQU WORD PTR 



(A)synchronous Reset 
Sequencer Restart 
VGA Memory Segment 
INPUT.l: Vert Retrace Bit 
Bits 0-1 of X = Plane # 
Used to mark end of list 
; Shorthand text 



EQU DWORD PTR ; macros for pointers 
= DGROUP STORAGE NEEDED (10 BYTES) ==== 



DW 



Offset of current Page 
Segment of VGA memory 
Width of a line in Bytes 
Current Display X Offset 
Current Display Y Offset 



; Mode X Mode list data table format... 
Mode.Data.Table STRUC 



M.MiscR 


DB 


? ? 
• j • 


Value of MISC.OUTPUT register 


M.XSize 


DW 


7 


X Size Displayed on screen 


M.YSize 


DW 


7 


Y Size Displayed on screen 


M.XMax 


DW 


7 


Maximum Possible X Size 


M.YMax 


DW 


7 


Maximum Possible Y Size 


M.CRTC 


DW 


7 


Table of CRTC register values 


Mode.Data.Table ENDS 





.CODE ; Data Tables put in CS for easy access 
; CRTC Register Values for Various Configurations 



MODE.Single.Line: 
DW 04009H 
DW 00014H 
DW 0E317H 
DW nil 
MODE.Double.Line: 
DW 04109H 
DW 00014H 
DW 0E317H 
DW nil 
M0DE.32O.Wide: 
DW 05F00H 
04F01H 
0S002H 
08203H 
05404H 
08005H 
nil 



DW 
DW 
DW 
DW 
DW 
DW 



MODE.360.Wide: 
DW 06B00H 



DW 
DW 
DW 
DW 
DW 
DW 



05901 H 
05A02H 
08E03H 
0SE04H 
08A05H 
nil 



; CRTC Data for 400/480 Line modes 

Cell Height (1 Scan Line) 

Dword Mode off 

turn on Byte Mode 

End of 400/480 line CRTC Data 
; CRTC Data for 200/240 Line modes 

Cell Height (2 Scan Lines) 

Dword Mode off 

turn on Byte Mode 

End of 200/240 Line CRTC Data 
; CRTC Data for 320 Pixels 

Horz total 

Horz Displayed 

Start Horz Blanking 

End Horz Blanking 

Start H Sync 

End H Sync 

End of 320 pixel CRTC Data 
; CRTC Data for 360 Pixels 
Horz total 
Horz Displayed 
Start Horz Blanking 
End Horz Blanking 
Start H Sync 
End H Sync 

End of 360 pixel CRTC Data 



30 GAM E DEVELOPER • DECEM BER 1994 



Listing 3. Modex.asm (Continued on p. 32) 


HUUt_zUU_ 1 dXX. 




MHHP Add Tall - 
rlUL/C_H-UU_ 1 dXX. 


\ \, ua la TOT ZUU/ H-UU LXNc IllOtJca 


L/W UDrUOn 


Vcr LXLdX lULdX 


L/W UlrUin 


n if ts iw i 
uver txow 


[HI OQHOH 


V oy lie Ldr L 


l/w uotiin 


V Oy ML CNU / riOL \,\ U Lr I 


L/w uorizn 


VcrLXLdX L/XbUXdycQ 


L/w uyuion 


U R~l anl/ Q-har-l- 
V DXdllK Oldi L 


nu 0RQ1 AM 

Urn uDJlUn 


\\ Rlank Fnd 

V DXdllK LIIU 


DW nil 


Fnd of 900/400 1 inp fRTf Oata 


MHHF *MO Tall • 
nuuc_ZH , u_ i nil. 




MHHP AftO. Tall - 
rlUUC_H-OU_ 1 nil. 


rPTT n^-ha -frtr OAH/Afin 1 ina mnHac 
Lr\ 1 L UdLd TOr HOU LJ-llc IllUOcb 


L/W UUL/UDn 


Vc[ L±LdX lULdX 


DW 03E07H 


Overflou 


DW 0EA10H 


V Sync Start 


DW 08C11H 


V Sync End/Prot CrO Cr7 


DW 0DF12H 


Vertical Displayed 


DW 0E715H 


V Blank Start 


DW 00616H 


V Blank End 


DW nil 


End of 240/480 Line CRTC Data 


; Table of Display Mode Components & Index Table 


MODE.TABLE: 




DW offset MODE_320x200, offset MODE_320x400 


DW offset MODE_360x200, offset MODE_360x400 


DW offset MODE_320x240, offset MODE_320x480 


DW offset MODE_360x240, offset MODE_360x480 


MODE_320x200: 


Data for 320 by 200 Pixels 


DB 063h, 


400 scan Lines k 25 Mhz Clock 


DW 320, 200 


Displayed Pixels (X,Y) 


DW 1302, 816 


Max Possible X and Y Sizes 


DW offset M0DE.32O.Wide, offset MODE.200.Tall 


DW offset MODE.Double.Line, nil 


MODE_320x400: 


Data for 320 by 400 Pixels 


DB 063h, 


400 scan Lines k 25 Mhz Clock 


DW 320, 400 


Displayed Pixels X,Y 


DW 648, 816 


Max Possible X and Y Sizes 


DW offset M0DE.32O.Wide, offset MODE.400.Tall 


DW offset MODE.Single.Line, nil 


MODE_360x240: 


Data for 360 by 240 Pixels 


DB 0E7h, 


480 scan Lines k 28 Mhz Clock 


DW 360, 240 


Displayed Pixels X,Y 


DW 1092, 728 


Max Possible X and Y Sizes 


DW offset M0DE.36O.Wide, offset MODE.240.Tall 


DW offset MODE.Double.Line , nil 


MODE_360x480: 


Data for 360 by 480 Pixels 


DB 0E7h, 


480 scan Lines k 28 Mhz Clock 


DW 360, 480 


Displayed Pixels X,Y 


DW 544, 728 


Max Possible X and Y Sizes 


DW offset M0DE.36O.Wide, offset MODE.480.Tall 


DW offset MODE.Single.Line , nil 


MODE_320x240: 


Data for 320 by 240 Pixels 



DB 
DW 
DW 
DW 
DW 



0E3h, 
320, 240 
1088, 818 
offset MODE, 
offset MODE. 



MODE.320x480: 



DB 
DW 
DW 
DW 
DW 



0E3h, 
320, 480 
540, 818 
offset MODE, 
offset MODE. 



MODE.360x200: 



DB 
DW 
DW 
DW 
DW 



067h, 
360, 200 
1302, 728 
offset MODE, 
offset MODE. 



MODE.360x400: 

DB 067h, 
DW 360, 400 
DW 648, 816 



; 480 scan Lines k 25 Mhz Clock 
; Displayed Pixels X,Y 
; Max Possible X and Y Sizes 
320. Wide, offset M0DE.240.Tall 
Double.Line, nil 
Data for 320 by 480 Pixels 
480 scan Lines k 25 Mhz Clock 
Displayed Pixels X,Y 
Max Possible X and Y Sizes 
320. WIDE, offset MODE.480.Tall 
Single.Line, nil 
Data for 360 by 200 Pixels 
400 scan Lines k 28 Mhz Clock 
Displayed Pixels (X,Y) 
Max Possible X and Y Sizes 
360. Wide, offset MODE.200.Tall 
Double.Line, nil 
; Data for 360 by 400 Pixels 

; 400 scan Lines k 28 Mhz Clock 

; Displayed Pixels X,Y 

; Max Possible X and Y Sizes 



DW offset MODE.360.Wide, offset MODE.400.Tall 
DW offset MODE.Single.Line, nil 



int SET.VGA.M0DEX (int Mode, int Max.XPos, int Max.Ypos) 

Sets Up the specified version of Mode X. Allows for 
the setup of of a virtual screen which can be larger 
than the displayed screen. 

ENTRY: Mode.Type = Desired Screen Resolution (0-7) 

= 320 x 200 4 = 320 x 240 

1 = 320 x 400 5 = 320 x 480 

2 = 360 x 200 6 = 360 x 240 

3 = 360 x 400 7 = 360 x 480 

Max.Xpos = The Desired Virtual Screen Width 
Max.Ypos = The Desired Virtual Screen Height 

EXIT: AX = Success Flag: = Failure, -1 = Success 



SVM.STACK STRUC 

SVM.Table DW ? 

DD 1,7,1 

SVM.Ysize DW ? 

SVM.Xsize DW ? 

SVM.Mode DW ? 
SVM.STACK ENDS 

PUBLIC SET.VGA.M0DEX 



Offset of Mode Info Table 
DI, SI, DS, BP, Caller 
Vertical Screen Size Desired 
Horizontal Screen Size Desired 
Display Resolution Desired 
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Listing 3. Modex.asm (Continued on p. 33) 


SET.VGA.MODEX PRQC FAR 




PUSHx 


BP, DS, SI, DI 


; Preserve Registers 


SUB 


SP, 2 


; Allocate workspace 


MOV 


BP, SP 


; Set up Stack Frame 


; Make Sure Mode, X and Y Sizes are legal 


MOV 


BX, [BP] .SVM.Hode 


; Get Requested Mode # 


CMP 


BX, 8 


; 8 Modes max: Is it 0..7? 


JAE 


8SVM_BadModeSetup 


; If Not, Error out 


SHL 


BX, 1 


; Scale BX to word 


MOV 


SI, uptr MODE_TABLE[BX] ; CS:SI -> Mode Info 


MOV 


[BPl.SVM.Table, SI 


; Save ptr for later 


AND 


[BPl.SVM.XSize, 0FFF8h ; X size Mod 8 Must = 


MOV 


AX, [BPl.SVM.XSize ; 


Get Logical Screen Width 


CMP 


AX, CS:[SI].M.XSize ; 


Check against Displayed X 


JB 


6SVM_BadModeSetup ; 


Report Error if too small 


CMP 


AX, CS:[SI].M_XMax ; 


Check against Max X 


JA 


6SVM_BadModeSetup ; 


Report Error if too big 


MOV 


BX, [BPl.SVM.YSize ; 


Get Logical Screen Height 


CMP 


BX, CS:[SI].M.YSize ; 


Check against Displayed Y 


JB 


SSVM.BadModeSetup ; 


Report Error if too small 


CMP 


BX, CS:[SI].M.YMax 


; Check against Max Y 


JA 


8SVM_BadModeSetup 


; Report Error if too big 


; Make Sure there is Enough memory to Fit it all 


SHR 


AX, 2 ; 


# of Bytes: Line = XSize/4 


MUL 


BX 


; DX:AX = Total mem needed 


JNO 


SSVM.Continue ; 


Exit if Total Size > 256K 


DEC 


DX 


; Was it Exactly 256K??? 


OR 


DX, AX 


; (DX = 1, AX = OOOO) 


JZ 


6SVM_Continue 


; if so, it's valid. . . 


(SSVM.BadModeSetup: 




XOR 


AX, AX 


; Return Value = False 


JMP 


8SVM.Exit 


; Normal Exit 


(SSVM.Continue: 




MOV 


AX, 13H 


; Start with Mode 13H 


INT 


10H 


; Let BIOS Set the Mode 


0UT.16 


SC.INDEX, CHAIN4.0FF 


; Disable Chain 4 


0UT_16 


SC.INDEX, ASYNC.RESET ;(A)sync Reset 


OUT.8 


MISC.OUTPUT, CS:[SI].M.MiscR ;Set New Timings 


0UT.16 


SC.INDEX, SEQU.RESTART ; Restart Sequencer 


OUT.8 


CRTC.INDEX, 11H 


; Select Retrace End Reg 


INC 


DX 


; Point to Data 


IN 


AL, DX 


; Get Data, Bit 7=Protect 


AND 


AL, 7FH 


; Mask out Write Protect 


OUT 


DX, AL 


; And send it back 


MOV 


DX, CRTC.INDEX 


; Vga Crtc Registers 


ADD 


SI, M.CRTC 


; SI->CRTC Parameter Data 


; Load Tables of CRTC Parameters from List of Tables 


GSVM.Setup.Table: 




MOV 


DI, CS:[SI] ; Get Ptr to CRTC Data Table 


ADD 


SI, 2 ; Point to next Ptr Entry 


OR 


DI, DI ; A 


nil Ptr means that ue have 



JZ @SVM_Set_Data ; finished CRTC programming 
8SVM.Setup.CRTC: 



MOV 


AX, CS:[DI] ; 


Get CRTC Data from Table 


ADD 


DI, 2 ; 


Advance Pointer 


OR 


AX, AX ; 


At End of Data Table? 


JZ 


SSVM.Setup.Table ; 


If so, go get next Table 


OUT 


DX, AX 


; Reprogram VGA CRTC reg 


JMP 


short @SVM_Setup_CRTC 


; Get next table entry 



; Initialize Page & Scroll info, DI = 
8SVM.Set.Data: 

MOV CURRENT.PAGE, DI ; Offset into VGA memory=0 
MOV AX, VGA.SEGMENT ; Segment for VGA memory 
MOV CURRENT.SEGMENT, AX ; Save for Future LES's 
; Set Logical Screen Width, X Scroll and Our Data 



MOV SI, [BPl.SVM.Table 

MOV AX, [BPl.SVM.XSize 

MOV CX, AX 

SUB CX, CS:[SI].M.XSize 

MOV MAX.XOFFSET, CX 

SHR AX, 2 

MOV SCREEN.WIDTH, AX 

SHR AX, 1 

MOV AH, 13h 

XCHG AL, AH 

OUT DX, AX 



Get Saved Mode Info Ptr 
Get Display Width 
CX = Logical Width 
CX = Max X Scroll Value 
Set Maximum X Scroll 
Bytes = Pixels / 4 
Save Width in Pixels 
Offset Value = Bytes / 2 
13h=CRTC Offset Register 
Switch format for OUT 
Set VGA CRTC Offset Reg 



; Setup Data table, Y Scroll, Misc for Other Routines 
MOV AX, [BPl.SVM.Ysize ; Get Logical Screen Height 
MOV CX, AX ; 
SUB BX, CS:[SI].M.YSize ; 
MOV MAX.YOFFSET, CX ; 
; Clear all of VGA Memory 
0UT.16 SC.INDEX, ALL.PLANES.O 
DI, dptr CURRENT.PAGE 
AX, AX 



CX = Logical Height 
CX = Max Y Scroll Value 
Set Maximum Y Scroll 



LES 
XOR 
CLD 
MOV 
REP 
MOV 
8SVM.EXIT: 
ADD 
POPx 
RET 



CX, 8000H 

STOSW 

AX, OFFFFh 

SP, 2 

DI, SI, DS, 
6 



BP 



Select All Planes 
ES:DI -> A000:0 
AX = 
Block Xfer Forwards 
32K * 4 * 2 = 256K 
Clear video memory! 
Return Success Code -1 

Deallocate workspace 
Restore Saved Registers 
Exit Si Clean Up Stack 



SET.VGA.MODEX ENDP 



void SET.POINT (int X.pos, int Y.pos, int Color.Num) 

Plots a single Pixel on the active display page 

ENTRY: Xpos = X position to plot pixel at 
Ypos = Y position to plot pixel at 
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Listing 3. Modex.asm (Continued on p. 34) 



ColorNum = Color to plot pixel uith 



EXIT: No meaningful values returned 



SP.STACK 


STRUC 








DD 


? ? 
• j ■ 


BP, DI, Caller 


SETP. 


Color DB 


? ? 
• j ■ 


Color of Point to Plot 


SETP. 


.Ypos DW 


? 


Y pos of Point to Plot 


SETP. 


.Xpos DU 


? 


X pos of Point to Plot 


SP.STACK 


ENDS 







PUBLIC SET.POINT, READ.POINT 



C.FT PflTMT 


PROC FAR 




PUSHx 


BP, DI 


Preserve Registers 


MOV 


BP, SP 


Set up Stack Frame 


LES 


DI, dptr CURRENT.PAGE ; ES:DI -> AOOO:0 


MOV 


AX, [BPl.SETP.Ypos 


Get Line # of Pixel 


MUL 


SCREEN.UIDTH 


Get Offset to Line Start 


MOV 


BX, [BPl.SETP.Xpos 


Get Xpos 


MOV 


CX, BX ; 


Save to get shift Plane # 


SHR 


BX, 2 ; 


X offset (Bytes) = Xpos/4 


ADD 


BX, AX 


Offset = Offset + Xpos/4 


MOV 


AL, MAP.MASK 


Select Map Mask Register 


MOV 


AH, 0001b ; 


Start ./ Plane #0 (Bit 0) 


AND 


CL, PLANE.BITS 


Get Plane Bits 


SHL 


AH, CL 


Get Plane Select Value 


OUT. 16 


SC.Index, AX 


Select Plane 


MOV 


AL,[BP].SETP.Color 


Get Pixel Color 


MOV 


ES:[DI+BX], AL 


Drau Pixel 


POPx 


DI, BP 


Restore Saved Registers 


RET 


6 


Exit and Clean up Stack 


SET.POINT 


ENDP 





; int READ.POINT (int X.pos, int Y.pos) 

; Gets the color of a pixel at (X.Pos, Y.Pos) 

; ENTRY: X.pos = X position of pixel to read 
; Y.pos = Y position of pixel to read 

; EXIT: AX = Color of Pixel at (X.pos, Y.pos) 

RP.STACK STRUC 

DD ?,? ; BP, DI, Caller 
RP.Ypos DW ? ; Y pos of Point to Read 
RP.Xpos DW ? ; X pos of Point to Read 

RP.STACK ENDS 

READ.POINT PROC FAR 

PUSHx BP, DI ; Preserve Registers 

MOV BP, SP ; Set up Stack Frame 

LES DI, dptr CURRENT.PAGE ; ES:DI -> A000:0 

MOV AX, [BP]. RP.Ypos ; Get Line # of Pixel 





Mill 

HUl- 


oLKEEN.WlU 1 H 




fcet UTTset to Line otart 


rlUV 


DA , LDrJ . Kr.ApOS 




Get Xpos 


rlUV 


TY DY 
LA , DA 




Save to get shift count 


cup 


DA , I 


> 


a onset ^oyiesy Apos/'f 


ADD 


BX, AX 




UI 1 3CL U 1 1 be L ' AUUo/t 


MOW 


Al DPfln MAD 
AL, KLRU.IIflr 




GC Read Mask Register 


MOV 


AH, CL 




Get Saved Xpos 


AND 


AH, PLANE.BITS 




mask out Plane # 


0UT.16 


GC.INDEX, AX 




Select Plane to read in 


XOR 


AX, AX 




Clear Return Value 


MOV 


AL, ES:[DI+BX] 




Get Color of Pixel 


POPx 


DI, BP 




Restore Saved Registers 


RET 


4 




Exit and Clean up Stack 


READ.POINT 


ENDP 








void SET.UINDOU (int X.pos 


int Y.pos) 




Since a Logical Screen can 


be larger than the Physical 




Screen, Scrolling is possible. 


This routine sets the 




Upper Left Corner of the Screen to the specified Pixel. 




When called, this routine syncronizes the display to 




the vertical blank. 








ENTRY: X. 


JOS = # Of 


pixels to shift screen right 




Y. 


jos = # of lines to shift screen doun 




EXIT: No meaningful values returned 


SW.STACK 


STRUC 








DW ? ; BP 








DD ? ; Caller 




SW.Ypos 


DW ? ; Y pos of UL Screen Corner 


SW.Xpos 


DW ? ; X pos of UL Screen Corner 


SW.STACK 


ENDS 






PUBLIC SET.UINDOU 






SET.WINDOW 


PROC FAR 






PUSH 


BP 




Preserve Registers 


MOV 


BP, SP 




Set up Stack Frame 


; Check if our Scroll Offsets are Valid 


MOV 


AX, [BP]. SW.Ypos 




Get Desired Y Offset 


CMP 


AX, MAX.YOFFSET 




Is it Uithin Limits? 


JA 


SSW.Exit 




if not, exit 


MOV 


CX, [BP]. SW.Xpos 




Get Desired X Offset 


CMP 


CX, MAX.XOFFSET 




Is it Uithin Limits? 


JA 


SSW.Exit 




if not, exit 


; Compute proper Display 


start address to use 


MUL 


SCREEN.UIDTH 




AX=YOffset * Line Width 


SHR 


CX, 2 




CX / 4 = Bytes into Line 


ADD 


AX, CX 




AX=0ffset of UL Pixel 


MOV 


BX, AX 




BX=Desired Display Start 


MOV 


DX, INPUT.l 




Input Status #1 Register 
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; Wait if ue are currently in a Vertical Retrace 
8SW.WAIT0: 



IN AL, DX 

AND AL, VERT.RETRACE 

JNZ 6SW.WATJ0 



Get VGA status 

In Display mode yet? 

If Not, wait for it 



; Set the Start Display Address to the new uindou 



MOV 
MOV 
MOV 
OUT 
MOV 
MOV 
OUT 



DX, CRTC.Index 
AL, START.DISP.LO 
AH, BL 
DX, AX 

AL, START.DISP.HI 
AH, BH 
DX, AX 



We Change the Sequencer 
Display Start Lou Reg 
Lou 8 Bits of Start Addr 
Set Display Addr Lou 
Display Start High Reg 
High 8 Bits of Start Addr 
Set Display Addr High 



; Wait for a Vertical Retrace to smooth out things 



MOV 
8SW.WAIT1: 
IN 
AND 
JZ 



DX, INPUT.l 
AL, DX 

AL, VERT.RETRACE 
6SW.WAIT1 



Input Status #1 Register 

Get VGA status 
Vertical Retrace Start? 
If Not, uait for it 



Nou Set the Horizontal Pixel Pan values 



0UT.8 ATTRIB.Ctrl, PIXEL.PAN.REG ; Select HPP Reg 
MOV 
AND 
SHL 
OUT 
SSW.Exit: 
POP 
RET 

SET.WINDOW ENDP 



AX, [BP].SW_Xpos 

AL, 03 

AL, 1 

DX, AL 

BP 
4 



Get Desired X Offset 
Get # of Pixels to Pan 
Shift for 256 Color Mode 
Fine tune the display! 

; Restore Saved Registers 
; Exit and Clean up Stack 



void SET.TEXT.MODE (void) 
int SCAN.KEYBOARD (void) 

Routines for the Demo program, MODEX.C 
SET.TEXT.MODE - Sets the VGA to MODE 3 (80 col text) 
SCAN.KEYBOARD - Gets a Key from BIOS 

PUBLIC SET.TEXT.MODE, SCAN.KEYBOARD 



SET.TEXT.MODE PROC 

MOV AH, 

MOV AL, 3 
INT lOh 
RET 

SET.TEXT.MODE ENDP 



FAR 



= Set Mode Function 
Mode to Set = 3 
Call the VGA BIOS 
That's it! 



SCAN.KEYBOARD PROC 
MOV AH, OOH 
INT 16H 
RET 

SCAN.KEYBOARD ENDP 
end 



FAR 



Function #0= Read key 
Call Keyboard BIOS 
That's it! 
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MTV Meets 
CD-ROM! 




With the interface of Peter Gabriel's Xplora 1 
CD-ROM, you can interact, watch, resume, or 
quit your play. The color stripe on the side is 
the signature of Real World Records. 



If you are part of the M T V gener- 
ation, you are accustomed to play- 
ing N intendo or Sega and alter- 
nately listening to music or 
watching music videos. It's not 
surprising, then, that many musi- 
cians and game developers are 
joining forces and flocking to the 
CD-ROM playground— rushing to get 
a corner of the market. 

Old cartridge games are like new 
CD-ROM games; you see the land- 
scape of M arioland much like you see 
the island of M yst. Likewise, popular 
two-dimensional action games parallel 
new interactive music games; you hear 
bullets and punches much like you play 
with an interactive mixing board. 
Games aim for a multisensory impact; 
interactive music CD-ROM s feature 
puzzles and challenges for players. In 
both, you feel you are a part of the arti- 
ficial environment. You leave your 
desktop behind and enter a world of 
vivid imagination and carefully crafted 
creation to envision another three- 
dimensional realm. 

A gaming element can bring 
music to life and entice people to expe- 
rience music in a new, visual way. The 
music CD-ROMs available today 
enable players to interact with their 
favorite artists' clips and turn the pages 
of a musical memorabilia scrap book. 

Interactive music CD-ROM s are 
difficult to create, design, program, and 
develop. M ultimedia means there are a 
lot of things a game maker must 
address, polish, and then integrate 
together— and, like most development 
projects, it all comes together under 
tight deadlines. 



Two small production houses cre- 
ated particularly successful music CD- 
ROM products: Brilliant M edia in San 
Francisco, Calif., developers of Peter 
Gabriel's Xplora 1, and GraphixZone 
in Irvine, Calif., developers of Prince's 

Interactive. Let's take a look at 
these two game- like CD-ROMs. 

Gabriel's Xplora 1 

When you load Xplora 1, you hear 
world music— mystical flutes in snake- 
charmer tones. T hen you see a suitcase 
open; Peter Gabriel emerges from its 
depths to give you an overview of the 
landscape and explain the controls you 
will need on your exploration. H e gen- 
erously gives you your own suitcase 
with which to collect goodies along the 
way. (If you fill your suitcase, you earn 
icons and screen savers.) 

You remember a suitcase motif 
from his recent tour and realize this is 
no flat, dull video. The screen seems 
alive. Along the top of the screen are 
pictures you recognize from his U S 
album— each piece of art represents 
one of the songs from the album and 
each is done by a different artist. You 
begin to feel very at home with this 
interface. 

Along the side of the screen are 
icons that act as verbs— you control 
what happens. You can interact, watch, 
resume, or quit by pointing on the 
image and clicking. You click on pic- 
tures which correlate to songs, and you 
are transposed to another interface 
with a new menu. For example, you 
can access the song "D igging in the 
Dirt" by clicking on the appropriate 
icon— a painting of a shovel— and get 
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a bio on the artist who created the 
painting. You can watch the video, 
hear from the team who worked on the 
video, or watch an interview with Peter 
(by this time you are on a first- name 
basis with the man) who offers his 
reflections on the particular song. 

^'s Interactive 

Imagine playing M yst. Only it's star- 
trekky. And purple. Very purple. Wel- 
come to ^'s Interactive. While 
G abriel's game is more of an "interface 
game," *¥"s Interactive is more of a 
"place game," in which the player has 
the feeling of being placed in a futuris- 
tic environment. Instead of watching 
actors act, the player acts and plays. 
You use the cursor to motor around. 
The cursor is, of course, a symbol like 
this: It is purple and zipple-like in 
the M acintosh version, white and 
rotating in the PC version. 

You can turn, go forward, up, 
down, and all around. Instead of being 
presented with options, you are pre- 
sented with a mystery, and you must 
discover the solution on your own. It's 
very three-dimensional. Instead of a 
static feel, I nteracti ve has motion and a 
geographical dimension— a M yst-like 
environment with rich three-dimen- 
sional textures. You feel like you are on 
a voyage, a discovery. 

Peter's People 

Despite Peter Gabriel's acute interest 
in computer technologies, he didn't 
have his own C D-RO M project until a 
smart, plucky developer came along. 
M eet Steve N elson who, while at 
Claris (then a division of Apple) in 



Santa Clara, Calif., developed an 
object-oriented authoring tool for in- 
house users called Digital M ontage. 
After working with Apple in 1991, he 
realized the entertainment field was 
ripe and ready to harvest. W ith his 
licensing fee from A pple for D igital 
M ontage, Nelson founded Brilliant 
M edia. 

H is first project was a CD-ROM 
demo, which combined elements from 
Gabriel's So album with available art 
and text. Nelson had never met 
Gabriel, but he managed to show him 
the demo— and he loved it. 

Gabriel, who has always been on 
the proverbial cutting edge, was defi- 
nitely ready for something interactive. 
H is concerts, his killer videos, his phil- 
anthropic benefits are all major produc- 
tions where lights, sound, and action 
come together for an in-your-face and 
blow-your-mind sensory overload. 
Remember the music videos for his hits 
"Sledgehammer" and "Big Time"? 
(Reportedly, some unfortunate epileptic 
in Boston suffered a seizure from one 
of his videos. I'd call that using a medi- 
um to touch your audience.) 

Gabriel's involvement gave Bril- 
liant M edia access to a world of 
resources, such as Real World (which 
films many of G abriel's concerts and 
videos) and The Box magazine, another 
British- based company closely associ- 
ated with Gabriel. Such a consortium 
let Brilliant Media use much of 
Gabriel's existing media— song lyrics, 
interviews, images, movies, and graph- 
ics, as well as the several paintings 
Gabriel had commissioned by individ- 
ual artists to capture the essence of 



by Diane 
Anderson 

Using multimedia 
technology and gome 
elements, tino gutsii 
and innovative 
development houses 
mooed music's 
biggest stars — and 
gave the NTV 
generation a new 
medium to roch to. 
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Welcome to Gabriel's secret world. Each Interface element In Xplora 2 Is a doorway to a different 
experience. The ear takes you to Gabriel's World of Music and Dance, the eyes let you Into his 
personal file, the nose takes you behind the scenes to a recording studio and the Grammy's, the 
mouth lets you enter the US database, which Includes music, videos, artwork, and Interviews. 



each song on the US album. These 
paintings are what add the unique 
visual element to the audio and turn 
each song into a multimedia experi- 
ence. Jamesjohnson, who started as an 
intern at Brilliant M edia and soon 
became the company's digital produc- 
tion supervisor, jokes that even if Bril- 
liant M edia were to have produced a 
"crappy interface," the CD-ROM still 
would have been a success because of 
Gabriel's incredible material. As it 
turned out, the interface received acco- 
lades and awards, including the Inter- 
active M edia Festival's Sparky A ward. 

A major part of the collective 
design effort was the group of inde- 
pendent artists and contractors who 
were hired for a time to scan, color, 
and clean up images. Troy Daniels, a 
Bay Area graphic artist, was hired to 
create the game screen. H e remembers 
his time on the project. "Gabriel was 
very cool to meet and working with 
him made the experience unforget- 
table. H e inspired me. We all wanted 
to finish with a quality product." 

Gabriel not only incited enthusi- 
asm and generated the music, video, 
and art, he oversaw the entire project. 
Nelson met often with Gabriel while 
he was on tour to show him Brilliant 



M edia's progress. For the most part, 
Gabriel approved of Nelson's work- 
he just added creative elements to the 
production. Gabriel's unbelievable 
breadth of talent and interests, includ- 
ing WOM AD (World Of M usic And 
Dance), Amnesty International, and 



W itness (a project that equips those 
who suffer human rights violations 
with cameras and other technology to 
expose those violations) were included 
in the game. T hus, Xplora 1 is not just 
a rock video but a close-up of the artist 
and his passions. 

^'s People 

T he concept for I nteractive was initiat- 
ed by Prince— excuse me, t f v — but the 
design, programming, and porting of 
the game were the work of G raphix 
Zone. 

I n contrast to G abriel, s t v , and his 
production company, Paisley Park, 
were looking for developers. "Prince 
got the bug to be an interactive artist 
who wanted to express himself in a 
product like this," explains Dave 
Nichols, project director. and Pais- 
ley Park put the word out that they 
were looking for developers to propose 
ideas and show presentations for possi- 
ble approaches. N ichols and others at 
G raphix Zone worked hard to show 
Paisley Park what they could do. After 
looking at G raphix Zone's stuff, Pais- 
ley Park decided to go with them for 
the project. 




Stop! In the name of ...Prince (or rather, f). In $"s Interactive, the artist formerly known 
as Prince is the master of ceremonies, and players must solve puzzles to progress through 
the game's purple, interactive maze. 
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So, you want your game to have killer graphics. You've settled on something Inter- 
active, but aren't sure what the best development route Is. It looks like this will be 
a CD-ROM project, and there Is the prospect of making It an entertainment title. 
Where should you begin? Well, If all were for the best In this best of all possible 
worlds, you'd have the money to Invest In one of the Indy systems from Silicon 
Graphics (SGI) and take advantage of the UNIX multiuser operating system. Then, you'd 
have a gigabyte of hard disk space and multitasking would be painless. So would porting to 
Macintosh and PC platforms. However, If this Is on your wish list, make sure you have at 
least $5,000 to $25,000 for hardware alone and another $50,000 for necessary software: 
Alias's Eclipse ($5,995), Mentallx's PIxelFX ($1,600), Visigenic's Creative License 1.1 
($1,495), and Barco Graphlcs's Creator 5.2 ($17,000) and Strike ($18,000). Granted, appli- 
cations will run very quickly, but for that price they better. 

Wake up, you were dreaming. Unfortunately, you don't have the money to buy such extrav- 
agant dreams. And since CD-I and 3DO are not yet the standard, you've decided to stick to 
more traditional (and affordable) means. The PC looks like a good pick, but you remind 
yourself you want graphics and good ones. You want a three-dimensional world where 
sound and video combine to anesthetize the player. For your project, budget, and goals, 
Macintosh Is the choice. 

Surprisingly, some great games were developed on the Macintosh this year. Xplora 1 and 
Interactive are not Isolated anomalies. They aren't the only great Macintosh-developed 
games. Myst Is a perfect example. But there Is stiff competition from DOS and PC game 
makers. Doom has shared more wares than anyone would care to count. And Lucas's amaz- 
ingly lucrative product Rebel Assault was developed on the PC. It sold 500,000 Individual 
copies by the summer of 1994- not even a year after Its late November 1993 release. 
Myst sold 200,000 copies by April 1994- but that Is way before Its PC version even had 
time to pick up any steam. Give Myst some time selling to both Macintosh and PC con- 
sumers, and I'm sure Its commercial success will be overwhelming. Despite Its bugs, the 
Macintosh- made Myst Is a multlsensory, virtual-reality envelope pusher. 

However, this Is not a comparison or contrast of games, but an examination of developing 
on the Macintosh. And I must agree with Wayne Slkes that "the three-dimensional anima- 
tion graphics In Rebel Assault are excellent" ("Breaching the Rebel Base," Chopping Block, 
Sept. 1994). However, the relatively affordable graphics capabilities of Macintoshes have 
enabled creators of games to realize the aesthetic environments of their Imaginations. The 
pixels on a Macintosh screen are what make the difference. Even If PCs are more tenable, 
the presentation on Macintosh Is superior. Programming on PCs Is unequivocally smoother, 
but visual aspects of a game are crucial as well. 

Macintoshes have simply been the best three-dimensional performers. Who else has killer 
applications like QuickTime, Photoshop, Illustrator, Electric Image, and Strata? Now pro- 
grams like Live Picture by HSC Software let users work with really large files with FITS 
(Functional Interpolating Transformation System) technology. 

Many people Involved In such visual creation are artists (see David Slek's "Artist vs. Arti- 
san" In Artist's View, p. 63), not programmers; the Macintosh Is more user-friendly to such 
people. Of course, many computer novices get Involved In the production of such titles. 
Musicians, animators, and marketers are all Important players. 

Since Apple Infused the market with so many CD-ROM drives and Adobe first Introduced Its 
graphics applications to the Macintosh community, It seems logical that Macintoshes 
would be a natural place for CD-ROM developers to congregate. Competition from IBM with 
Its new Holiday '94 multimedia computers Is good for the Industry. 




N ichols explains that after the ini- 
tial hand-off from Paisley, Graphix 
Zone took over all the design and pro- 
duction of the project— they were the 
creative brains and the technical mus- 
cle. Of course, G raphix Zone showed 
Paisley the stages of progression and 
got feedback. It was a collaborative 
effort. Paisley supplied information, 
music tracks, and other material. Since 

is media-oriented, the "talent" in 
this case was very willing to cooperate. 

recorded a song and shot a video 
specifically for this project— something 
many developers hope artists will con- 
tinue to do in this medium, instead of 
simply recycling old stuff. 

Obviously, I nteractive's design 
needed to match ^'s persona— and it 
does. You sense throughout the 
experience. The game is seductive and 
mysterious— and purple. 

T he design and product were fun- 
damentally done at G raphix Zone, 
after the initial hand-off from Paisley. 
(Money makes things happen!) 
G raphix Zone completed the job in six 
months— just in time for ^'s birthday 
on June 7. 

Peter's Machines 

T he video "Kiss that Frog" on theX plora 
1 CD-ROM lucidly illustrates that 
Gabriel and the Brilliant M edia team 
had the help of human and technological 
resources. M indblender Rock M otion 
Theatre, a "ride" featuring quadraphonic 
sound and hydraulic seats, joined forces 
for the video aspect with video director 
Brett Leonard (Lawnmower M an). A.E. 
Bunker's sketches were scanned into Sili- 
con Graphics workstations and three- 
dimensionally animated at Angel Studios 
in Los Angeles. Leonard preconceived 
ideas on the computer using three- 
dimensional wire frames. T hey shot 
footage with Sony's H DTV camera. 

Viewers can reinterpret and reexpe- 
rience "Kiss that Frog" over and over 
again. It is a powerful blending of psy- 
chedelic graphics, organic textures, and 
primitive emotion. T he video makes 
viewers feel as if they are moving. Other 
videos on Xplora 1 don't have motion, 
but do contain morphsand other tricks. 
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Although Brilliant M edia didn't 
shoot the videos or write the songs, the 
company assembled them to create a 
cohesive and rich product. Program- 
ming this material into a tapestry 
required patience and skill. To put the 
whole thing together and add the 
interactive element, Brilliant M edia 
used its proprietary authoring system, 
Digital M ontage, a program based on 
HyperCard and developed by Nelson. 
T hink of D igital M ontage as Q uark or 
Pagemaker for multiple media. It lets 
the user lay out various digital infor- 
mation—text, images, video— into a 
seamless song. It allows multiple users 
to work on a file and coordinates "asset 
management" for a whole project. 

Because D igital M ontage is based 
on H ypercard, it provided extensibility. 
For the trippy morphs and sleights of 
hand, HyperCard let Brilliant Media 
control the architecture of the game. 
W e all know multimedia is about com- 
munication— not just between people 
but between programs. Digital M on- 
tage took advantage of H ypercard's 
capabilities. Other important tools 
Brilliant M edia used included: 
• D igital Film Board by SuperM ac (to 
digitize video) 
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Prince represents himself with this sym- 
bol- which is seen throughout his 
Interactive CD-ROM, 



• VideoFusion by VideoLake (for cre- 
ating effects) 

• Photoshop by Adobe (to create and 
manipulate PICT, TIFF, and EPS 
files) 

• Premiere by Adobe (to digitize and 
edit digital video) 

• A fterE ffects by CoSa 

• QuickTime and M ovieShop by 
Apple 

• SoundD esigner by D igidesign 
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Choosing from diverse facial features, 


players of Xplora 1 must put together 


Peter Gabriel's passport photo. 





• Video Vision and PL I 

• A 1.07G B turbo drives. 

T hese products helped N el son 
and his crew tackle the most H erculean 
task of all— the particular challenge of 
dealing with video footage. In Eng- 
land, the video standard is PA L ; in the 
U.S., it isNTSE, which made for 
some difficulty. H owever, James John- 
son managed to be a competent liaison; 
he coordinated communications 
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Watch an image magically change before your very eyes. Morphs for Interactive were done 
in Elastic Reality. 



between Real World and Brilliant 
M edia and managed the vast sound 
files, photo PICTS, and video clips 
involved. It was imperative these 
resources were not damaged, destroyed, 
or lost, and so archiving was vital. Not 
only did Johnson get an education in 
management; he learned a lot about 
technology. Fortunately, Digital M on- 
tage allows for easy tracking of 
changes— an important benefit for such 
collaborative projects. 

Machines 

From a creative and technical stand- 
point, Nichols says the people at 
Graphix Zone feel pleased with their 
work on Interactive. Design and pro- 
gramming aspects were nearly painless 
with their authoring tool, Apple M edia 
Tool. They needed Apple M edia Tool 
to create the main part of the program 
and then extend into other areas, some- 
thing possible from other programs like 
H ypercard. H owever, other script lan- 
guages aren't as powerful as C is and will 
only allow you to do limited things "in 
addition to y'know making a movie 
player, being able to turn left or right or 
whatever," says N ichols. 



The first part of the Apple M edia 
T ool works like D i rector — only simpler. 
You sacrifice some control but you get 
the same mapping or staging. The sec- 
ond part of the tool is a variation of the 
C programming language called Apple 
M edia Programming Language. This is 
a custom language that allowed the team 
to design what it wanted to as far as 
navigation, graphics, and the integration 
of audio and video in a real simple inter- 
face. Because the designers wanted to do 
custom things like adding a mixer (a DJ 
booth where you can select CDs and 
play them in a player), the team used 
Apple M edia Kit, which enabled them 
to code in their own features when they 
wanted to do something above and 
beyond Apple M ediaTool. 

Other code-intensive projects 
required programming— a puzzle in the 
virtual video room, morphs in the 
church, and so on. M orphing was done 
in E I astic Reality. N ichols claims Apple 
M edia made it much easier on the 
development team. 

The Pain of Porting 

Porting is perhaps the biggest chal- 
lenge developers face today, and one 



they must face if they want to cater to 
a wide audience. M any developers use 
M acromedia's D irector, which enables 
developers to port their games to both 
PC and M acintosh platforms. 

D igital M ontage enabled the 
Brilliant M edia team to complete the 
project in nine months, but it didn't 
provide a straight PC link. Brilliant 
M edia released X plora 1 for the M ac- 
intosh only and went to an outside 
company in E ngland to provide the 
CD-I and PC ports. At press time, a 
PC version of X plora 1 was about to be 
released. 

G raphix Z one's A pple M edia 
Tool compiles for M acintosh and 
Windows platforms, which reduced 
their porting worries. Not only did 
I nteracti ve ship on time (thanks to the 
tool), but it was able to run on both 
platforms. 

What's Next? 

Big names like Prince and Peter 
Gabriel mean big bucks for developers 
who can create great games that work. 
Brilliant M edia is now working on 
other multimedia projects for Disney 
and W arner Bros., and a C D -RO M 
movie project featuring Richard D rey- 
fuss. The exposure Brilliant M edia 
received for its pioneering work on the 
collaborative X plora 1 title couldn't 
have hurt its chances of winning such 
bids. 

G raphix Zone's next project is for 
Bob Dylan— quite a change from «¥*. 
N ichols says that coordinating with 
talent is challenging, but his real inter- 
est is getting inside the minds of stars 
and figuring out their styles. Where 
does N ichols see the future? "I want to 
try to continue to do that same thing 
— extend the use of both technology 
and the ability to communicate some- 
thing that represents the artist accu- 
rately and in an entertaining way." 

T he egomaniacal 'f* is at it again. 
This time he's back with a male- 
fern ale- arrow- mirror- symbol -deal. 
G raphix Zone made the new symbol 
its navigating cursor. I'd call that an 
accurate representation— and an enter- 
taining one. 
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Modern J ukebox. Click on an icon, get a song. Xplora 1 pleases your eyes, your ears, and your 
mind. 



Break on Thru 
to the Other Side 

Not only have multimedia merged, but 
industries have as well. M aking tran- 
scendent computer experiences is not 
easy. T he aim of games and the prospect 
of virtual reality promise the possibility 
of transporting a person sitting in front 
of a computer into another environ- 
ment. Players should forget they are 
using a computer and be unaware of the 
mouse or keyboard as they attempt to 
grasp another dimension. 

For so long, stories have helped 
people enter new worlds, and music 
has aided in soothing the stress of life 
by connecting us with a spiritual aspect 
of sound. Now interactive C D -RO M s 
offer us an illusion of control. Interac- 
tive multimedia is cool. A lot of things 
are multimedia— meals, poetry read- 
ings, concerts, movies— but the inter- 
active element is what intrigues our 
human nature. 

Hollywood, Silicon Valley, Sili- 
wood. It looks like information and 
entertainment are coming together 
more and more. Technology didn't 
only make the M TV generation, it is 



now responsible for Kurt Cameron, 
T ia C arrere, D ennis H op per, and 
Stephanie Seymour showing up in 



CD-ROMs this year. C onversely, 
Doom and M ortal Kombat will be 
starring in movie theaters near you 
soon. Television commercials are more 
cyber-aware these days. Technology 
(represented by the image of a laptop 
screen), coupled with an icon of coun- 
terculture, is used to advertise tennis 
shoes of all things. I ntel I nside pops up 
between Letterman skits. Conversely, 
one of our favorite Saturday N ight 
L ive personalities is featured in a com- 
mercial advocating the C D -I platform. 
Strange, but big- name designers can be 
found not only on the pages of fashion 
magazines, but on the pages of our 
favorite techno- savvy, slick, and oh-so- 
very-90s 'zines. 

This proves a very symbiotic rela- 
tionship—entertainment need be tech- 
nical and technology is entertaining in 
and of itself. ■ 



D iane Anderson is the editorial 
assistant at G ame D eveloper. 



PORTING 



Macromedia User Journal #27 gives this advice: "To distribute Director 4 
movies to Windows users, you need to create a projector using the Win- 
dows version of Director 4. To distribute Director 4 movies to Macintosh 
users, you need to create a projector using the Macintosh version of Direc- 
tor 4. In both cases, the projector file can then call the same Director 4 
movie files. The only restriction on movie files is that they are named in accordance with 
PC naming conventions." Another word on Director: Since Microsoft seems to enjoy seeing 
its Windy City operating system repeatedly renamed (Windows 4 or Windows 95), there 
has not been OLE 2.0 support for Director's Windows version. But Macromedia has good 
news for gamers, it looks like OLE 2.0 support will happen if Microsoft ever comes 
through. 

Beware of differences in color- a display on Windows has lower color depth, and so col- 
ors don't look the same. Some VGAs can show 16 colors and some can show 256. Making 
a movie look the same on all platforms is no easy task. Sound is also better on a Macin- 
tosh. These individual aesthetic elements (mediums) are the individual parts that, when 
assembled together, make the mu/t/ the operative part of multimedia. 

Macromedia's Director is a good tool to use if you are concerned with making a game that 
runs on both PCs and Macintoshes. Neither platform has complete dominance (especially 
with all these strange, rumored mergers and buyouts), so it seems smart to put your game 
out as many ways as possible. Visibility means marketability for your company- compe- 
tition is the name of this multimedia game we're playing. 
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1200 High! 




Pacific Strike sends the player- acting as fighter pilot- on battle missions based on real- 
life occurrences (Pearl Harbor, Midway, and the like). Here, a Japanese Val plane has just 
been targeted. 



Up next on the chopping block is 
Pacific Strike by Origin Sys- 
tems Inc. Pacific Strike is an 
action- oriented aircraft simula- 
tion based in the Pacific theater 
during W orld W ar 1 1 and was 
written using Origin's Real- 
Space Technology. Although 
this review centers on Pacific Strike v. 
F 1.19, I included the speech pack (sold 
separately) in my analysis. 

Once installed, Pacific Strike uses 
about 20M B of hard disk space and 
requires 583K of conventional memory as 
well as at least 4M B of XM S (extended) 
or EM S (expanded) memory. Ideally, the 
game wants expanded memory, so the 
JEM M .OVL expanded memory manager, 



included with Pacific Strike, will automat- 
ically run whenever the user's computer 
only hasXM S memory available. (Origin's 
JEM M. OVL was written by Jason 
Yenawine— J E M M is probably a 
mnemonic for "Jason's Expanded M emory 
M anager.") If you have trouble running 
the game, the included OSITEST.EXE 
routine, a carryover from Strike C omman- 
der, will diagnose your system and make 
recommendations for running Pacific 
Strike. (I saw no mention of this routine 
in the game literature.) 

How it Works 

Pacific Strike's primary executable, 
PACIFIC.EXE, is about 1M B in size 
and is not compressed or encrypted. It 
was written using the Borland C ++ 
Development System. This file contains 
essentially all the executable code in the 
game. M y analysis showed the presence of 
a built-in cheat mode (although I haven't 
yet figured out how to access it), plus lots 
of internal diagnostics. PACIFIC.EXE 
requires a minimum of a 80386 processor 
and runs the game in protected mode. 
Comparisons of PACIFIC.EXE and the 
INSTALL.EXE file show that the devel- 
opers made provisions for two add-on 
mission packages. Of particular interest 
was my discovery of embedded 
PKWARE data compression functions. (I 
later discovered that most of the graphic 
terrain data was stored in Zl P format, so 
the presence of a "pkunzip" function 
makes sense.) 

Essentially all game data is contained 
in the PAC I F I C .DAT file. T his large file 
(about 16M B in size) contains 600 data 
files. I will refer to these embedded data 
files as File Records. L isting 1 gives a 
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general summary of how PA C I F I C .D AT 
is organized. Basically, you can break 
PACIFIC.DAT into three parts: 

• An 8- byte header 

• A list of 74- byte File D escription 
R ecords. 

• A list of File Records. 

The header gives the total number 
of File Records and the file offset of the 
first File Record (see the PACIFICDATHEADER 
example in Listing 1). Following the 
header are File D escription Records. 
Each 74-byte File Description Record 
contains information about a File Record, 
such as the path name of the original data 
filemaking up the File Record, where the 
File Record is located in PACIFIC.DAT 
(expressed as an offset from the top of the 
file), and the size (in bytes) of the File 
Record. In other words, each File 
Description Record "points" to its corre- 
sponding File Record— as in the 
FILEDESCRIPTTONRECORD structure in Listing 
1. (I n this review, I will frequently refer to 
File Records using their original data file 
name. For example, the Corsair aircraft 
data is contained in the CORSAIR. IFF 
File Record.) 

The File Records constitute most of 
the space in PACIFIC.DAT. These 
records vary in size from a few to several 
hundred thousand bytes and contain the 
actual "pieces" of game data. M any differ- 
ent types of File Records are stored in 
PACIFIC.DAT. M ost File Records have 
an IFF file name suffix; out of 600 File 
Records, 511 are of the I F F type. 

What is an IFF File Record? 

The IFF file name suffix is possibly a 
mnemonic for "Information Form File." 
An I FF File Record is a structured, vari- 



able-length file whose design allows for 
an open-ended, expandable format. 
(Origin Systems has used the IFF File 
Record format in several games includ- 
ing Privateer and Strike Commander. 
M y PRE D IT, PR EASY, and SCEASY 
"help" utilities modify various IFF File 
Records in these games.) Basically, an 
IFF File Record is made up of one or 
more forms, with each form containing 
one or more records. Following are a 
few general rules for IFF File Record 
construction. 

• All forms have a header consisting of 
the "form" text string followed by a 4- 
byte number. This number is the num- 
ber of data bytes in the form. 

• All records have a header consisting of 
a name (that can be up to 8 bytes of 
text characters) followed by a 4- byte 
number. This number is the number of 
data bytes in the record. 

• Records can be located both inside and 
outside a form. 

• N ever change the form or record header 
name, and never change the total num- 
ber of data bytes in these structures. 
Violation of these rules will most likely 
cause a system crash. (Actually, you can 
change the number of record data bytes 
but be very careful when restructuring 
any forms that may enclose the record.) 

I extracted most mission and aircraft 
data discussed in this article from IFF 
File Records. The next two sections dis- 
cuss how missions and aircraft are "built" 
by the game engine, using the IFF File 
Records. 

Mission Anatomy 

Essentially all mission data is stored in 
IFF File Records. The name of a mission 



by Wayne Sikes 

Whaf mokes the best 
gomes fly? Flexible 
doto structures. 
Wop Sikes presents 
o novigotion plan to 
steer you tbrougb tbe 
ins. outs. ups. ond 
douins ofPocific 
Strike. 
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File Record contains the geographic loca- 
tion of the mission and the number of the 
mission at that location. W hen the game 
engine chooses a mission to play, it opens 
and reads the I F F File Record corre- 
sponding to the mission. The first cam- 
paign mission is centered around the 
Pearl H arbor area. The mission data is 
located in IFF file PRLH-M 1.IFF 
(PRLH-Mlisa mnemonic for Pearl 
H arbor M ission 1). The game engine first 
scans the File D escription Records in 
PACIFIC.DAT until it finds a reference 
tothePRLH-M 1.1 F F File Record. nee 
the correct File Description Record is 
located, the offset and size data are used 
to locate and read the PRLH -M 1.IFF 
File Record. 

The mission IFF File Record con- 
tains several internal records describing 
the various mission parameters. The 
mission structure is somewhat complex, 



so I will only describe a few of the more 
interesting records. 

T he WRLDFILE record gives the name 
of the IFF File Record containing the ter- 
rain data for the player's location. The 
primary geographical areas the player will 
interact with are in the AREA record. This 
record contains the name and XYZ-coor- 
dinate data of each important location — 
for example, airfields, ships, enemy 
encampments, navigation waypoints, and 
the like. 

The game's three-dimensional 
XYZ-coordinate system is interesting. 
Pacific Strike references all world objects 
using a 24- bit coordinate system. If you 
imagine the world (or an area of it) dis- 
played as a flat map, movement in the X- 
axis direction goes east-west with positive 
(+X) movement going east. M ovement in 
theY direction goes north- south and pos- 
itive (+Y) movement heads north. The Z- 



Listing 1. The PACIFIC.DAT File Structure 



HEADER 

Bytes 0-3 Number of embedded File Records. 
Bytes 4-7 Offset of the first File Record. 

FILE DESCRIPTION RECORDS 

Bytes 8-XX File Description Records. Each record is 74 

bytes long. XX = 7 + (74 * Number of File Records) 

FILE RECORDS 

Bytes (XX+D-EOF File Records. 



EXAMPLE HEADER AND FILE DESCRIPTION RECORD C STRUCTURES 
#define BYTE unsigned char 
struct PACIFICDATHEADER 

{ 

long NumFileRecords; // offsets 0-3 

long FirstRecordOffset; // offsets 4-7 

}; 

struct FILEDESCRIPTIONRECORD 

{ 



BYTE 


Unidentifiedl; 


// 


offset 0, always value of 1 


char 


0riginalPathFileName[32]; // 


offsets 1-32 


BYTE 


Unidentified2[33]; 


// 


offsets 33-65 


long 


FileRecordOffset; 


// 


offsets 66-69, PACIFIC.DAT 






// 


FILE RECORD OFFSET 


long 


FileRecordSize; 


// 


offsets 70-73, FILE RECORD 






// 


SIZE 



}; 



axis goes above- below the map and can be 
considered as altitude referenced to sea 
level. Positive (+Z) movement means 
increased altitude. Using cockpit altitude 
measurements and data from Area 
Records, I calculated a map scale factor of 
1 XYZ unit equals 1 meter. I used this 
scale factor to calculate the size of the 
Pacific Strike "world." This world mea- 
sures about 10,500 miles on a side for a 
total of about 110 million square miles. 
T he center of this world, at XYZ coordi- 
nates (0, 0, 0) is the center of the terrain 
map currently being used. An example C 
structure for the area record data is given 
in L isting 2. 

T he CAST record lists the names of 
the IFF File Records containing dialog 
box text and other information used by 
the cast members. Each cast member has 
a C ast M ember N umber. Rather than ref- 
erencing cast members by name, the game 
engine references each cast member using 
a predefined C ast M ember N umber. 

E ach cast member plays a part in the 
mission, and the PART record defines each 
member's role. See L isting 2 for an exam- 
ple C structure for PART record data. E ach 
cast member has a data structure in the 
PART record. The cast member structure 
references the cast member by its Cast 
M ember N umber and contains IFF File 
Record names for files describing the 
member and any associated weapon loads 
as well asXYZ-coordinate data giving the 
starting location of the cast member rela- 
tive to the AREA location in which this 
member belongs. Finally, this structure 
contains various control bytes specifying 
the actions of the member. 

Aircraft Construction 

Aircraft data is stored in IFF File 
Records. These records generally have a 
file name similar to the type of aircraft 
being described, for example, the F4F3 
Wildcat data is stored in the F4F3.IFF 
File Record. The aircraft IFF File Record 
contains records describing various air- 
craft parameters Because the overall air- 
craft description is rather complex, I will 
again only discuss a few of the more 
interesting records. 

The JETPHNME record (mnemonic for 
"JET Pilot NaM E") is interesting because 
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it shows that much of the Pacific Strike 
game engine came directly from Strike 
Commander. After all, why would a 
World-War-ll aircraft name be in a 
record referencing jet aircraft? 

The flight modeling is contained in 
the TOFF, LAND, DYNMDYMM, STBL, ATMO, THRS, 
and JDYN records. T he DYNMDYNH record (see 
Listing 2 for an example C structure) 
contains the approximate weight of the 
aircraft in increments of 600 pounds. For 
example, the weight of a 4,200- pound 
aircraft would be given as 7. bviously in 
this flight model, the exact weight is not 
very important. The STBL record contains 
a data byte representing the overall stabil- 
ity of the aircraft. These values ranged 
from an unstable H elldiver (40 decimal) 
to a very stable Bearcat (131 decimal). If 
you reduce the value of this parameter to 
less than 20, your aircraft will never be 
stable enough to fly. Increase this value to 
get better handling. 

The ATMO record appears to contain a 
measure of the overall atmospheric drag 
or total air resistance of the aircraft. The 
Baka (a very sleek, rocket- powered Japan- 
ese aircraft) had an ATMO record data- byte 
value of 51 (decimal), and the large and 
heavy J apanese Betty had a value of 230 
(decimal). If the ATMO record data value is 
too high, your aircraft will have so much 
drag that you will never get off the 
ground. Conversely, very small values will 
give you almost no air resistance— that is, 
they will create inertia similar to flying in 
space vacuum conditions. It will take you 
a long time to bleed off enough speed for 
landings. 

The THRS record contains aircraft 
thrust and propulsion data. Refer to L ist- 



ing 2, which gives an example C structure 
for THRS record data. Byte offsets 5 and 6 
in this structure form a 16- bit value that 
represents aircraft engine horsepower. 
This horsepower value sometimes differs 
from the values referenced in the game 
literature (probably due to programmer 
"tweaking" to make the game more 
playable). Of course, changes in engine 
horsepower ratings will drastically affect 
aircraft performance. D rag factors are 
located at byte offsets 12 and 16. The 



drag factor at byte offset 12 appears to be 
used in calculating the amount of lift 
required for take-off, while the value at 
offset 16 is a drag element used for calcu- 
lation of stall speed. Increasing the value 
at offset 12 results in higher takeoff 
speeds, and increasing the value at offset 
16 results in higher stall speeds. General- 
ly, the two drag factors have almost iden- 
tical values. 

T he WPNS record data consists of one 
or more 10- byte structures. Each struc- 
ture references one weapon type. Listing 
2 gives an example WPNS structure. The 
first two bytes in the structure contain the 
weapon load (number of bullets, bombs, 
and the like), and the last eight bytes give 
the name of the I F F F ile Record that 
contains detailed weapon information. 
The names of the weapon File Records 
correspond with the weapon type, for 
example, 20M M .IFF (20-mm cannon), 
50CAL.IFF (.50-caliber machine gun), 
and B1000LB.IFF (1,000- pound bomb). 

The HPTS record data defines where 
the weapons referenced in the wpns record 
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are mounted on the aircraft. See L isting 2 
for an example of the HPTS data structure. 
E ach mount point on the aircraft is called 
a "hardpoint" and is defined by a 13- byte 
structure. ne or more of these structures 
make up the HPTS record data. The first 
byte in the structure gives the hardpoint 
type. Surveys found the following hard- 
point types: 

• Type 0: .50-caliber machine guns, 
20mm cannons, and 7.7mm machine 
guns 

• Typel: H igh- Velocity A eri al Rockets 

• Type 2: 100- and 551- pound bombs 

• Type 3: 500- and 1,000- pound bombs, 
N apalm, M K- 13 Torpedoes 

• Type4: 12.7mm machine guns 

T he last 12 bytes in each HPTS record 
data structure give the location of the 
hardpoint expressed in aircraft XYZ coor- 
dinates A ircraft coordinates are represent- 
ed as 32-bit signed numbers. The X-axis 
stretches from wingtip to wingtip, theY- 
axis stretches from the nose of the plane to 
the tail, and the Z-axis extends from the 
top to the bottom of the aircraft. rigin's 
aircraft coordinate system follows the 
standard "right-hand rule" (for those of 
you who remember a little bit of physics). 
T he or center reference position (0, 0, 0) 
is approximately the location of the pilot 
seat in the cockpit. Using references to 
aircraft dimensions given in the game lit- 
erature and various HPTS record data sam- 
ples, I calculated a rough XYZ -coordinate 
scale factor of 12 XYZ coordinate units 
equals 1 inch of distance on the aircraft or 
144 XYZ coordinate units equals 1 foot. 
For example, assume you are sitting in the 
cockpit of a Corsair and you increase the 
X-axis coordinate of a gun mount hard- 
point from 400 to 544. Looking out the 
right side cockpit window onto the wing, 
you would notice the gun mount had 
moved about one foot away from you. 

Undocumented 
Keyboard Features 

Several useful keystrokes are not docu- 
mented in Pacific Strike's game literature. 
N ote that some of these are active only in 
certain portions of the game. D uring 
game startup and while onboard the carri- 
er, the A It- V keystroke reads out the game 
version and the state number. The game 



Listing 2. Several Types of RECORD Data (Continued on p. 59) 



#define BYTE 
#define WORD 



unsigned char 
unsigned int 



// Data in AREA Record 

// Note there are Type C and S AREA RECORD data. The type is determined 
// by the contents of AreaType. The Type C and S data are different sizes, 
struct AREA.TypeC 



{ 

BYTE 


AreaType; 


// offset 0, C char 


char 


AreaName[33] ; 


// off 1-33, text or 0x2E 


long 


XAxis; 


// off 34-37, X pos of object 


long 


YAxis; 


// off 38-41, Y pos of object 


long 


ZAxis; 


// off 42-45, Z pos of object 


WORD 


AreaWidth; 


// off 46-47 


WORD 


BlankO; 


// off 48-49 


WORD 


AreaHeight; 


// off 50-51 


BYTE 


Blankl; 


// off 52 



}; 



struct AREA.TypeS 



{ 

BYTE 


AreaType; 


// 


offset 0, S char 


char 


AreaName[33] ; 


// 


off 1-33, text or 0x2E 


long 


XAxis; 


// 


off 34-37, X pos of object 


long 


YAxis; 


// 


off 38-41, Y pos of object 


long 


ZAxis; 


// 


off 42-45, Z pos of object 


WORD 


AreaWidth; 


// 


off 46-47 


BYTE 


BlankO; 


// 


off 48 



}; 

// Data in DYNPIDYNM Record 
struct DYNMDYNM 
{ 

unknounO; 
unknounl; 
AirplaneWeight; 
unknoun2; 



BYTE 
BYTE 
BYTE 
BYTE 

}; 



// off 
// off 1 

// off 2, real wt in lbs/600 
// off 3 



// Data in HPTS Record 
struct HPTS 
{ 

Type; 
XAxis; 
YAxis; 
ZAxis; 



BYTE 
long 
long 
long 

}; 



// off 0, Hardpoint type 0-4 
// off 1-4, X pos of hardpoint 
// off 5-8, Y pos of hardpoint 
// off 9-12, Z pos of hardpoint 



// Data in PART Record 
struct PART 
{ 

WORD MemberNumber; 
char MemberName[16] ; 
char WeaponLoad[8] ; 
WORD UnknounO; 
WORD Unknounl; 
long XAxisRelatiue; 



// off 0-1, Cast Member Number 
// 2-17, IFF File Record name 
// 18-25, IFF File Record name 
// 26-27 
// 28-29 

// 30-33, X pos rel to AREA 
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Listing 2. Several Types of RECORD Data (Continued from p.58) 



long YAxisRelatiue; 

WORD ZAxisRelatiue; 

BYTE Controls [22]; 

}; 



// 34-37, Y pos rel to AREA 
// 38-39, Z pos rel to AREA 
// 40-61, various control bytes 



// Data in THRS Record 



struct THRS 




BYTE 


Blank0[5] ; 


// off 0-4 


WORD 


HorsePouer; 


// off 5-6, Engine HP 


BYTE 


Blankl; 


// off 7 


BYTE 


FlagsO; 


// off 8 


BYTE 


Flagsl; 


// off 9 


BYTE 


UnknounO; 


// off 10 


BYTE 


Blank2; 


// off 11 


BYTE 


Dragl Factor; 


// off 12, 1st drag factor 


BYTE 


Blank3[3] ; 


// off 13-15 


BYTE 


Drag2 Factor; 


// off 16, 2nd drag factor 


BYTE 

}; 


Blank4[2] ; 


// off 17-18 


// Data 


in WPNS Record 





struct WPNS 

{ 

WORD WeaponLoad; 
char WeaponName[8] ; 

}; 



// Number of bullets, bombs, etc 
// Weapon IFF File Record name 



engine references missions using prede- 
fined State N umbers. W hen you are in 
the cockpit during a mission, this same 
keystroke reads out the Version and the 
M ission name. The M ission name is 
essentially the name of the I F F File 
Record that contains the mission data. 
Pearl H arbor M ission 1 has an I FF File 
Record name of PR L H -M 1.1 F F and 
would be displayed with Alt-V as 
"PRLH M 1." 

Thegame also includes some built-in 
diagnostics you can activate via the Shift- 
D and Shift- F keycodes. Both keycodes 
are active only while the player is in the 
cockpit. The Shift- D keycode toggles a 
readout containing display and memory 
usage parameters, including frame rate (in 
frames per second). The Shift-F keycode 
toggles a readout of the display frame rate 
only. T he A It- F keycode displays the 
game score. 

Experimenting with 
Pacific Strike 

D uring the course of this analysis, I pre- 
pared a "Pacific Strike Experimenter's 



Kit" to experiment with game data. The 
kit includes PSD AT, an analysis and data 
modification tool you can use for extract- 
ing and inserting File Records into Pacific 
Strike. It also includes several X-Wing 
aircraft that I built using aircraft File 
Records. (I refer to these aircraft as X- 
W ings because I repositioned the gun 
mount hardpoints on the wingtips so that 
they appear to fire in an X-W ing man- 
ner.) T hese experimental X-W ing aircraft 
are much faster and have more firepower 
than the original game vehicles. The 
Experimenter's Kit (PSKIT.ZIP) isin the 
Flight Simulation Forum (GO FS 
FORUM ) on CompuServe, H istoric Air 
Combat Library. 

Does It Fly? 

ne of the messages that rigin released 
regarding Pacific Strike was that the 
game tries "to raise the standard in terms 
of technology, graphics, sound and 
music— every aspect of the gaming expe- 
rience." M y analysis of Pacific Strike 
shows this to be the case, but as with all 
evolving technology, numerous problems 



exist. Overall, theRealSpace game engine 
worked well but it could still use some 
improvement in the graphics rendering 
and updating areas. 

RealSpace was also used in Strike 
Commander, and I noticed a definite 
carryover of old Strike C ommander data 
in Pacific Strike. Some Pacific Strike 
File Records appeared to be littered 
with data such as unused pieces of 
Strike Commander missions. W hile 
doing the analysis for my SC EASY and 
SCEDIT Strike Commander utilities, I 
observed that the Strike Commander 
data was very cleanly organized and 
grouped. Pacific Strike seems to be a 
product that was hurriedly thrown 
together using the Strike Commander 
engine. The presence of unused Strike 
Commander mission data is a good 
example of the "we are behind schedule 
and on a tight budget, so just make it 
run" philosophy many game companies 
currently operate with. 

The philosophy behind the Real- 
Space file formats used for data storage, 
that is, IFF File Records, allows for an 
open-ended, expandable gaming environ- 
ment. T he price for this technology is 
longer time delays during game startup 
and updating (while the various File 
Records are being processed), and more 
stringent requirements regarding comput- 
er system speed and memory usage. (I 
turned off all the sky and water texturing 
options while doing this analysis and I 
often achieved a frame rate on my 
486DX 2/50 of only five frames per sec- 
ond.) I guess its about time for that 
90M H z Pentium upgrade. ■ 



Wayne Sikes has been a computer 
hardware and software engineer for the last 
10 years. H ehasan extensive background in 
C, C++, and assembly language program- 
ming. H e also has several years experience as 
a computer systems intelligence analyst, 
where he specialized in dedphering and dis- 
assembling computer axJe w hi le working on 
classified government projects. H e has 
authored numerous computer gaming help 
utilities. H e can be reached via e-mail at 
70733.1562@compuserve.com or through 
G ame D eveloper magazine. 
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Re i n ve nting 
the Death Star 




ne-dimensio 

and true three-dimensional polygon objects. In this case, the characters walking around on 
the deck are two-dimensional bitmaps while the spaceship and surrounding spacestation 
are polygon- based with bitmaps wrapped around them. 



In an era where most movie compa- 
nies are trying to get into the com- 
puter game industry, one company 
has been there for a while. L ucasA rts 
E ntertainment and its sister compa- 
ny, Lucasfilm, both formed by Star 
Wars creator George Lucas, have 
been in the thick of both industries 
for almost a decade. W hile the companies 
are totally separate, they have found a cre- 
ative synergy in L ucasA rts games based on 
Lucasfilm movies. 

A Ithough both G eorge L ucas and 
LucasArtsCEO Randy Komisar have 
publicly criticized the digital H ollywood 



movement, the close relationship between 
these two companies has helped L ucasA rts 
reap the benefits of G eorge L ucas's movie- 
making vision. 

Using the Force 

T he influence of Star Wars can be felt 
throughout many computer and video 
games— from the hyperspace button in 
Asteroids to the space dogfights in W ing 
Commander. The Star Wars story first 
appeared in games in a series of coin- oper- 
ated arcade games developed by Atari in 
the early 1980s, which featured sequences 
loosely based on scenes from the three Star 
W ars movies: Star W ars, T he E mpi re Stri kes 
Back, and Return of the J edi . The first two 
were three-dimensional space combat 
games using vector- based, wire-frame 
graphics to show action. The third game, 
Return of thejedi, used more convention- 
al, sprite- based color graphics and featured 
game play from an isometric three-dimen- 
sional perspective. 

To capitalize on the exploding video 
game market, in 1982 Lucasfilm formed a 
computer game division called Lucasfilm 
Games. From 1982-1987, acting solely as 
a developer, Lucasfilm Games turned out 
games such as Rescue at Fractalis and Ball 
Blazer. I n 1987, L ucasfilm G ames became 
a publisher, and in a corporate restructur- 
ing move eventually became what it is 
today, L ucasA rts E ntertainment. 

After developing coin-operated 
arcade games, L ucasA rts wanted to better 
establish itself in the game market and dis- 
tance itself from the shadow of the Lucas 
empire. A nd so, the company began devel- 
oping games for home computers that had 
nothing to do with Star Wars Its first titles 
were the point- and- click adventure games 
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M aniac M ansion, Zak M cKracken and 
the Alien M indbenders, Loom, and the 
Secret of M onkey Island, most of which 
were created using its own SCUM M 
(Script Creation Utility for M aniac M an- 
sion) game engine. 

L ucasA rts next entered the flight 
simulator genre, with games such as Bat- 
tlehawks 1942 and Secret W eapons of the 
Luftwaffe. It was from this experience 
making flight simulators that Star Wars 
reemerged in the computer game world. 

A License to Develop 

LucasArts' computer game division had 
first crack at the license to create games 
based on all of G eorge Lucas's films. This 
relationship worked well on films such as 
Indiana Jones and the Last Crusade, which 
had multiple computer games released in 
conjunction with it. This partnership even 
produced I ndiana Jones and the Fate of 
Atlantis, a computer game- only episode of 
the I ndiana Jones saga. Unfortunately, by 
the time this licensing arrangement was 
established, the Star Wars film series had 
come to an end. 

But Star W ars games returned in a 
big way in 1991, with the release of X- 
W ing, a game featuring Star Wars charac- 
ters and themes. In X-W ing, players pilot 
an X-W ing fighter plane (similar to Luke 
Skywalker's in theoriginal Star Wars) from 
training missions up to destroying the 
D eath Star. T he X-W ing design team 
integrated the repair and management of 
the X-W ing's resources into the game, 
which added to the game's realism and 
improved long-term payability. The com- 
bination of LucasArts' experience with 
flight simulator games, a game engine 
similar to rigin's W ing C ommander 



series, and Star Wars iconography, made 
X-W ing a smash hit. 

X-W ing was so successful that one 
supplemental mission disk made PC 
Data's best seller list by itself. The game 
eventually spawned a sequel called Tie 
Fighter. 

After this success, L ucasA rts investi- 
gated making more games with the Star 
Wars license and the result was another 
hit, Rebel Assault. This game was more 
episodic and had more linear game play 
than X-W ing, and it relied more on cap- 
tured video images, including some taken 
directly from the original Star Wars film. 
Rebel Assault was also among the first 
games to come out on C D-RO M for the 
PC and became an early success story for 
this product category. 

Dark Forces 

Continuing its trend of using the Star 
Wars license to showcase cutting- edge 
technology, L ucasA rts joined the ranks of 
Doom-style games with its latest entry, 
Dark Forces. In this game, the player 
fights storm troopers as a secret agent for 
the Rebel Alliance. 

W hile the game's lead programmer, 
Daron Sinnett, admits his team studied 
Doom's design, he insists that the Dark 
Forces game engine is 100% original. H e 
speculates, however, that the data struc- 
tures might be close enough that a conver- 
sion program could convert one file struc- 
ture into the other. 

A clear difference between the two 
games is the design environment that the 
Dark Forces design team used. W hile the 
D oom development team used a N extStep 
environment with its own tools, the Dark 
Forces design team used a DOS- based 



by Alexander 
Anton lades 

LucosHrrs is keeping 
Darin Voder's name 
alive around the 
office by 
continuously coming 
up mith neui games 
using iconography 
from the Star Wars 
film series. 
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design environment with Watcom's C 
compiler 10.0 and A utoC A D release 12. 

T he D ark Forces team chose A uto- 
CAD over other rendering packages 
because most of the designers were for- 
mer architects more accustomed to using 
CAD software. A dedicated programmer 
customized theAutoCAD interface using 
extensions to add elements such as light- 
ing and wall textures. In the end, devel- 
opers used the base A utoCA D program 
mainly for the geometry of building the 
space. 

F or the games X-Wing and Tie 
Fighter, LucasArts used a general- pur- 
pose, polygon-based engine that could 
render pretty much any object from the 
Death Star to a space buoy. The Dark 
Forces engine is more specific in design. 
It combines a true three-dimensional 
engine to render the objects in the game 
and a flat bitmap manipulation engine to 
render the characters. L ucasA its is look- 
ing to make the performance acceptable 
on a 486/33M H z machine with a report- 
ed frame rate of 30 fps on a 486/66M H z. 
This game engine is called— appropriate- 



ly enough— the J edi, and LucasArts 
hopes to use it again in future games. 

A shift in the market toward CD- 
ROM games caused LucasArts to 
decide— halfway into the project— to make 
Dark Forces CD-RO M based. This 
allowed the game to have more elaborate 
animation sequences, but the size of the 
remaining game code was comparable in 
size to a floppy-disk-based game. Indeed, 
the overall design of the game is more sim- 
ilar to the disk- based, X-W ing- style games 
than the CD -based Rebel Assault. 

Star Wars, according to Sinnett, is 
ingrained into the culture of LucasArts. 
T he basic design of all Star Wars games is 
open ended, to the point that designers can 
do almost anything they want. No direct 
link exists between the various games in 
the Star Wars license, so every game can 
end with Darth Vader meeting some hor- 
rible new fate. 

T he licensing division of L ucasfilm is 
involved only when a game introduces new 
characters to the Star Wars pantheon. An 
example is the Dark Trooper, a new class 
of storm trooper introduced in Dark 



Forces. This character had to be approved 
by licensing and, ultimately, by George 
Lucas himself. 

The Future 

LucasArts is looking toward the future 
with a variety of projects in the computer 
entertainment area, such as Commander, a 
programmable interactive simulator that 
can be an airplane, a submarine, or a 
spaceship. A nother project is a multimedia 
network project with Japanese giant Fujit- 
su involving a multiplayer Doom-style 
game with a Star Wars theme. And, 
G eorge L ucas is rumored to have some 
new Star Wars movies in the works, which 
will undoubtedly spawn new games to cap- 
italize on the films' inevitable popularity. 

Regardless of these projects, one 
thing is certain: whatever the outcome in 
the interactive entertainment boom and 
the Si licon- V al ley- meets- H ollywood 
craze, one of George Lucas's companies 
will be right in the middle of it ■ 

Sander Antoniades is G ame D evelop- 
er's editor- at- large. 



62 GAM E DEVELOPER • DECEM BER 1994 



ARTIST'S VIEW 



Artist 

vs. Artisan 



by David Sieks 

H paradigm shift has 
begun in the game 
industry — arcade 
action now coincides 
ujitti Art itself. So what 
does that make us? 
Game developers or 
(Irteests? 



I had spent the morning climbing 
counter-clockwise, spiraling up 
through cloistered rooms and spaces 
lovingly lit; altars to artistic genius. 
Past the beautiful, the daring, the 
exhilarating; past M iro and Picasso, 
past Kandinsky and Klee. Finally, at 
the very top of M anhattan's 
Guggenheim M useum— that corkscrew 
through the pulpy core of M odern A it— I 
arrived at Kosuth. 

"Clear, Square, Glass, Leaning," an 
installation piece by Joseph Kosuth, con- 
sists of four clear squares of glass, leaning 
side by side against the wall at a slight 
angle. As I arrived on the scene, a young 
art critic in pigtails and pink stockings was 
attempting to ferret some meaning from 
this piece as her mother looked on. 

I n the center of each glass square is 
lettered a word in neat, white type. Pacing 
studiously the length of the installation 
and pointing her small finger at each word 
in turn, she read aloud, proudly, in a clear 
contralto. "Clee-ur ... Squay-ur ... Glass 
...urn..." 

M other was there to assist. "Lean- 
ing," she offered. "Leaning," repeated the 
waif, regarding the Kosuth with delicately 
furrowed brow. "Leaning, M ommy? Is 
that what makes it Art?" 

Art Who? 

I relate that 100% Guaranteed Genuine 
No B.S. anecdote to you here because I 
think it crystallizes the confusion in our 
society surrounding the very notion of art. 
W hat it is and, conversely, what it isn't. 
W hat does any of this have to do with 
game development? R ead on. 

Art, as a label, intends to validate 
both the artist and the work. T he attempt 



is not always successful, because broad- 
based agreement as to what qualifies as 
Art is hard-won. Even once the label has 
been made to stick, the question exists as 
to what quality content it assures. "I don't 
know art, but I know what I like" has long 
been wielded as a sharp pin to deflate such 
assumptions of worth. 

M any people like computer games, 
though few, if any, would think to define 
them as A rt. Some game developers 
might contend that the act of creating an 
entertaining game is an art form, yet even 
they would hesitate to acclaim the end 
result a work of art. G ames are diversion, 
fun for fun's sake. I n any case, the very 
word "game" carries with it a connotation 
of frivolity that effectively serves to pre- 
vent more serious consideration. 

The visual artist involved in the pro- 
duction of a game fares little better, 
respectability- wise. Generally, our cre- 
ations are rarely considered Art, and we 
are considered more artisans than true 
artists, probably ranking lower on the 
totem pole than the more traditional vari- 
eties of commercial artist. This is partly 
because we are associated with a frivolous 
product and also because of the medium 
itself, which has, until recently, delivered 
game graphics that are relatively crude. 

A New Medium 

Of course, the rapid pace of technology 
has changed all the familiar rules. The 
realm of possibility with computer graph- 
ics becomes ever more stunning. It is no 
longer uncommon to find the dazzling 
products of sophisticated graphics soft- 
ware gracing magazine covers, on televi- 
sion, in major films, and even featured in 
galleries as, you guessed it, A rt. 
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ARTIST'S VIEW 




Art? Dogfight was created by Designers' 
CADD Co. of Cambridge, Mass., using sam- 
ple 3DStudio geometry and plug-ins from 
Yost Group Inc. 



W ith the full range of multimedia 
capabilities now so commonly available, 
the games of today— or more to the point, 
those of tomorrow— are not, in a manner 
of speaking, your father's Idsmobile. N ot 
only has it become possible to make games 
that are neater looking, better sounding, 
and more smoothly interactive, but sud- 
denly (relatively so) we have at hand tools 
truly fit for the artist and a new medium 
for meaningful creative expression. 

Yes, I'm talking about computer 
games. W hy not? T he art world has tradi- 
tionally met encroaching technology with 
resistance (ask any airbrush artist). Y et, the 
computer is too powerful and flexible a 
tool to be so ostracized. W itness its near 
ubiquitous presence in the design field. 

H ow's this as a vehicle for creative 
expression: graphics tools that allow live- 
action video, photo-illusion, and emula- 
tion of traditional drawing and painting 
media with a palette of colors vastly 
greater than that offered by any paint 
manufacturer; quality stereo sound; an 
ever- more- responsive array of interface 
options that allow the audience to become 
an active participant. W ith the list of pos- 
sibilities growing almost daily, the com- 
puter game can become not only an art 
form, but an unprecedentedly interactive, 
malleable form of art, guided by the 
artist/game designer and uniquely shaped 
by the audience/ user. 

T he time is ripe for a paradigm shift, 
where society acknowledges the computer 
game as a veritable art form fully as expres- 
sive as the novel, film, theater, ballet, 
opera. Capable of instilling wonder, of 



exciting the imagination, of provoking 
thought, of captivating its audience. Capa- 
ble of beauty. I n a word, A it. 

Feet Back On the Ground 

W hat, you may be asking yourself, does 
this have to do with the two-way scrolling 
shooter I want to make to run on the 386? 
M aybe not much at all. Using the available 
technology for meaningful creative expres- 
sion is a new possibility, not a new man- 
date. T he computer game was born out of 
far simpler pleasures, and there is doubt- 
less much vigor, joy, and profit left in the 
familiar arcade genres. 

Someone out there is probably clever 
and creative enough to figure out a way to 
make arcade action and art coincide in a 
16-bit cartridge. The paradigm shift I 
called for earlier begins within the indus- 
try. There are indications that it already 
has begun. 

By now you might easily have heard 
more than you ever wanted to hear about 
Broderbund Software's M yst (especially if 
you're the jealous type). B rodurbund's suc- 
cess is remarkable, though, because they 
dispensed with elements that seemed near- 
ly indispensable— fluid action, readily 
identifiable goals, violence— and delivered 
a hauntingly evocative, beautifully ren- 
dered game. I n a different way, I nfogames' 
Alone in the Dark defied convention as 
well by incorporating a shifting "cinemat- 
ic" viewpoint that introduced to computer 
games new possibilities for storytelling 
power and depth. A fresh use of viewpoint 
also buoys System Shock, from Looking 
G lass Technologies. By combining what 
they call a"6-D" perspective with highwire 
tension, they keep the player literally peer- 
ing around each corner, attaining a level of 
audience immersion any H ollywood direc- 
tor would envy. 

T remendous talent exists in the field 
today, and gaming horizons are constantly 
being stretched— if in mostly familiar 
directions. But that's what paradigms are 
all about. T hey're tough to shake. T he cre- 
ative impulse to make something more 
than "just a game" will not likely come 
from a game developer looking to make a 
better version of something we've already 
seen, which is in itself a noble effort. All 
games don't need to aspire to the level of 



Art, nor should they. I can hardly imagine 
anything more tedious. 

A New Role 

At the same time, all games would profit if 
artists were given a greater role throughout 
a game's development. People in the 
industry tend to use "the talent" as tools- 
tell them only as much as they need to 
crank out their little segment and make 
sure they do as they're told— like some sort 
of Al-Paint program. (I can hear pro- 
grammers drooling at the very idea of 
being able to realize their game concepts 
without relinquishing one iota of control, 
but no, such software does not yet exist. 
Just last issue, though, this magazine pro- 
filed software that can compose tunes 
given only thematic guidance by the user. I 
doubt it's made many friends amongst liv- 
ing, breathing, bill- paying musicians.) 

W hat's lost by such an approach is 
potentially valuable creative input that 
could nudge a game in directions 
unthought of. W hat sort of game might 
develop if the Tenderers and musicians 
were sitting at the table from the earliest 
brainstorming sessions? W hat new ways 
might be conceived to interweave talent 
with technology, playabi I ity with beauty, 
strategy with color and sound? Fantastic 
collaborations are waiting to happen. Vast 
new horizons await exploration. 

I 've found myself dreaming lately of a 
day when the N ew York Times reviews 
interactive computer art with the same 
highbrow intensity it devotes to cinematic 
and literary efforts. M aybe, someday, I'll 
make my way to the very top of the 
G uggenheim and find there a small child 
staring rapt into a glowing screen that 
responds to each whispered command, 
that whispers back and hums and sings 
and fills that topmost corner of the muse- 
um with gentle swirls and eddies of sound. 
The parent, smiling quietly in the back- 
ground, will be visibly pleased that the 
child shows such appreciation for fine art. 

It may be a farfetched conceit, but 
that's my job— I'm an artist. ■ 

Send your thoughts on art and artists in 
the game industry to D ave Sieks at G ame 
Developer, or e-mail him at dsieks@ 
arnarb.harvard.edu. 
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